Re: [Emc-developers] uspace

[Valerio Bellizzomi]

On Sat, 2020-06-13 at 23:40 -0400, Gene Heskett wrote:
> On Saturday 13 June 2020 20:53:36 andy pugh wrote:
> 
> > Is there an expectation that a uspace package would work on whatever
> > realtime system it found itself on, or would we need separate builds
> > for preempt-rt, xenomai and rtai-lxrt?
> 
> What diff would it make if you are spinning an iso?  Spin it for whatever 
> flavor runs best.
> 
> Preempt-rt, particularly with helper cards, has had little or no problems 
> getting the job done to my satisfaction on the two copies of the intel 
> D525-MW board that I own, one even doing software stepping for several 
> years, until it unscrewed a switch protected ball nut and scattered 
> balls all over.  And my bag of balls I had restuffed those nuts with a 
> decade back cannot now be found.  So that D525MW and all the motor 
> drivers that go with it is running the 6040, rather nicely but it grew 
> some mesa help in getting moved from the old hf mill.  With the mesa 
> help it can do rapids at 200 ipm.
> 
> I built a zenomai system to replace a BDI but before I could formulate an 
> opinion, a wheezy based iso appeared and thats still running on 3 of my 
> 4 machines. So I don't know a lot about zenomai.
> 
> My 4th machine is an armhf running buster with a preempt-rt kernel that 
> gets 16 u-secs latency but that dissolves to 200 u-secs while starting 
> firefox. But I don't run FF on that and cut metal. Nothing else seems to 
> bother it. Running with a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT I built, 
> getting long in the tooth now, but the rest of the install is uptodate 
> buster and the currently running LinuxCNC is the buildbots master.  All 
> have been updated in the last 2 days.


FireFox is historically slow to fire up, I could not even start it up on
armhf raspberrypi with Gnome. I tried Xfce but there is a login loop,
ended up installing LXDE which is not too bad.

> > I did try the experiment of running the current buildbot 2.8-preemtrt
> > package on an RTAI system and it chose to use POSIX non-realtime.
> >
> > I am trying to write some explanatory notes for the 2.8 release, and
> > so would like to know if what I observed is what would be expected.
> 
> So, do what you think is the best for the "normal" user. Keep in mind 
> that everything today is 64 bit, a place few of us has jumped into on 
> our work machines. I expect some teething problems we'll have to work 
> out.
> 
> But I have confidence that won't be as big a problem as our imagination 
> is telling us. :)
> 
> Cheers, Gene Heskett




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] quirks of ngcgui [update]

[Reinhard]

Hi,

I tried ngcgui with option "--vert" but then the window is resizable vertical 
only and horizontally fixed to a with of about 4mm.
The width is 2 borders and a breath of nothing from the client area.

Then I considered myself as astute and tried both variants, but only the 
latter is taken :(


A start of pyngcgui shows what every py/glade/vcp- app shows:
== snip =
Xlib:  extension "RANDR" missing on display ":0".
Traceback (most recent call last):
  File "/usr/local/src/linuxcnc-dev/bin/pyngcgui", line 2, in 
import pyngcgui
  File "/usr/local/src/linuxcnc-dev/lib/python/pyngcgui.py", line 72, in 

from gladevcp import hal_actions
  File "/usr/local/src/linuxcnc-dev/lib/python/gladevcp/__init__.py", line 1, 
in 
from .hal_pythonplugin import *
  File "/usr/local/src/linuxcnc-dev/lib/python/gladevcp/hal_pythonplugin.py", 
line 42, in 
from .hal_sourceview import *
  File "/usr/local/src/linuxcnc-dev/lib/python/gladevcp/hal_sourceview.py", 
line 27, in 
import gtksourceview2 as gtksourceview
ImportError: No module named gtksourceview2
== snap =

I run out of ideas.


cheers Reinhard





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] uspace

[Gene Heskett]

On Saturday 13 June 2020 20:53:36 andy pugh wrote:

> Is there an expectation that a uspace package would work on whatever
> realtime system it found itself on, or would we need separate builds
> for preempt-rt, xenomai and rtai-lxrt?

What diff would it make if you are spinning an iso?  Spin it for whatever 
flavor runs best.

Preempt-rt, particularly with helper cards, has had little or no problems 
getting the job done to my satisfaction on the two copies of the intel 
D525-MW board that I own, one even doing software stepping for several 
years, until it unscrewed a switch protected ball nut and scattered 
balls all over.  And my bag of balls I had restuffed those nuts with a 
decade back cannot now be found.  So that D525MW and all the motor 
drivers that go with it is running the 6040, rather nicely but it grew 
some mesa help in getting moved from the old hf mill.  With the mesa 
help it can do rapids at 200 ipm.

I built a zenomai system to replace a BDI but before I could formulate an 
opinion, a wheezy based iso appeared and thats still running on 3 of my 
4 machines. So I don't know a lot about zenomai.

My 4th machine is an armhf running buster with a preempt-rt kernel that 
gets 16 u-secs latency but that dissolves to 200 u-secs while starting 
firefox. But I don't run FF on that and cut metal. Nothing else seems to 
bother it. Running with a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT I built, 
getting long in the tooth now, but the rest of the install is uptodate 
buster and the currently running LinuxCNC is the buildbots master.  All 
have been updated in the last 2 days.

> I did try the experiment of running the current buildbot 2.8-preemtrt
> package on an RTAI system and it chose to use POSIX non-realtime.
>
> I am trying to write some explanatory notes for the 2.8 release, and
> so would like to know if what I observed is what would be expected.

So, do what you think is the best for the "normal" user. Keep in mind 
that everything today is 64 bit, a place few of us has jumped into on 
our work machines. I expect some teething problems we'll have to work 
out.

But I have confidence that won't be as big a problem as our imagination 
is telling us. :)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] uspace

[andy pugh]

Is there an expectation that a uspace package would work on whatever
realtime system it found itself on, or would we need separate builds
for preempt-rt, xenomai and rtai-lxrt?

I did try the experiment of running the current buildbot 2.8-preemtrt
package on an RTAI system and it chose to use POSIX non-realtime.

I am trying to write some explanatory notes for the 2.8 release, and
so would like to know if what I observed is what would be expected.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] quirks of ngcgui

[Reinhard]

Hi,

for testing purpose I wanted to try ngcgui.

When I called ngcgui from commandline, I first wondered, why nothing happens. 
Terminal looks like program is running but no change on screen?

Well, the change was so small, that I didn't realize it a first sight.
Application size is about 4mm wide and almost 20mm high. Of cause - nothing is 
readable.
So I tried to resize the window using the mouse.
The problem is, that ngcgui allows horizontal size changes only.
Even if I use maximize buttons or (kde-only feature) maximize window 
vertically only - no way to change the height of application.

With the horizontally grown app I can read a Box with the title "Controls", 
which has a button (?) called "Präambel", which triggers a file selection.
But even on selecting a file, nothing changes to the application window size.

Any hint, how I can resize the window vertically?


cheers Reinhard





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Setting the RTAPI debugging level

[andy pugh]

In some kernels you can set the RTAPI debugging level with:
echo 5 > /proc/rtapi/debug

But that seems to have stopped working at some point.

So I have added a "debug" command to halcmd.

halcmd debug 5

(or "debug 5" in a HAL file) will now turn on all debug messages.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] HUMM, good code won't run

[Gene Heskett]

On Friday 12 June 2020 18:07:09 Gene Heskett wrote:

> Greetings all;
>
> updated the master/wheezy on th G0704 earlier today, then opened up
> the nema 34 mount to pass the spindle end of a nema 23 motor.  I
> carved that square pattern without any hickups not of my doing, but
> that adapter plates boltholes for the nema 23 weren't tapped.
>
> Saddled up and went to TSC where I took them out of 5x.8 x 10's and
> 12's cap screws.
>
> Come back, load up lcnc and home it, put the head in low gear, and
> load the code below.
>
> ( tap5mmx.8mm pitch-hole.ngc )
> ( to tap the holes for screws in the saddle of the Sheldon or for any
> 5mm threaded hole)
> ( working in metric )
> G21 g7 ( measure in mm's & diameter)
> ( setup a path for data from this file to hal, in this case the tpmm
> for g33.1's -kval)
> #<_tpmm> = .800
> #<_z_depth> = -10.00
> #<_z_dec> =   [ #<_z_depth> / 10]  ( go a bit farther each time)
> (debug, z_dec=#<_z_dec>)
> #<_z_tmp> =   0.
> G1 F750 z0.
> ( center at touched off x, don't touch Y )
> S200 M3
> o100 WHILE [#<_z_tmp> ge #<_z_depth>]
> M68 E0 Q#<_tpmm>
> G33.1 Z#<_z_tmp> k#<_tpmm>
> #<_z_tmp> =   [#<_z_tmp> + #<_z_dec>]
> G4 P3 (3 second pause to blow chips & buttercut the tap )
> o100 ENDWHILE
> M5
> G0 z75
> M2
> %
>
> This code ran fine the last time I used it, but now a click on go
> starts the spindle, spindle-at-speed is solidly true, but it never
> execs the first of 10 loops. Nor does it highlight the problem line.
> clues anybody, or a real bug?

I found it, but no clue why its failing. I had replaced the 
spindle-index "generator" with an ATS-667, sensing a section of a steel 
screw glued to the side of the spindle below the drawbar cap. Inside the 
green motor cover. I can see thru the dust cap hole that the screw is 
still there and the ATS-667 is still in position, but the index 
according to the hal meter is forever true. So the why it won't run is 
obviously no index. I can't get a scope probe on it without removing the 
cover.  With my hoist for the BS-1 hanging there, that will not be fun 
and it will wait for daylight.  And fresh coffee.

> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers