Advanced Search

As a first step, get the encoder counting so that you can see a "counts" pin incrementing when you turn the encoder.
There are a few ways to do this mentioned above, and there is always the possibility of using the software encoder counter too, connected to GPIO pins,

Once you have the counts HAL pin working, that then needs connecting to all the axis (and joint) jog-counts pins. You then wire the switches to set the jog-enable pins of the axes/joints as required,

For the actual pin names see:
linuxcnc.org/docs/stable/html/man/man9/m...n.9.html#AXIS%20PINS

linuxcnc.org/docs/stable/html/man/man9/m....9.html#JOINT%20PINS

And possibly linuxcnc.org/docs/stable/html/man/man1/h...html#Joint%20jogging

But prefer the pins in "motion" to those in "halui" as the former run in realtime and so are more dependable.

I think that this is a consequence of the system trying to get into the same state after a run-from-line request.
But it does rather assume a toolchanger and/or repeatable length tools.

Rather than re-post the toolpath, you should be able to to comment-out the preceding tool changes in the G-code file. (Just don't forget to un-comment them, or save the modified file under a new name)

Which LinuxCNC version are you running? I think that there have been various attempts to improve run-from-line over the years.

There is discussion, but no conclusion, here: github.com/LinuxCNC/linuxcnc/issues/246#issuecomment-423049528

No change.
How do I access and view syslog?
 

I have already asked in another estop related chat but maybe that was too old of a thread.
I have been trying to incorporate the rather complicated estop relais functionality from the original machine setup and have messed up my estop logic along the way and can not recover from all changes i have made in the meantime.
Even the easy setup i am running right now is unable to recover GUI estop from True status. I have checked behaviour in halscope and everything seems to work correctly, except somethings holding on to halui.estop.is-activated. I can find nothing about what kernel nets exist, linking internal pins to ...is-activated. What problem could be the source of that behaviour?
Thank you all


net not_aus_fault     => halui.estop.activate

setp oneshot.0.width 0.1
setp edge.0.in-edge FALSE          
setp timedelay.0.on-delay 0.05     
setp timedelay.0.off-delay 0
net not_aus_ok         => iocontrol.0.emc-enable-in
net not_aus_ok         => edge.0.in
net estop-ok-rising    <= edge.0.out => oneshot.0.in
net estop-reset-raw    <= oneshot.0.out => timedelay.0.in
net estop-reset-pulse  <= timedelay.0.out => halui.estop.reset

 

'toggle2nist.comp' up to and including 2.9.x has issues:
github.com/LinuxCNC/linuxcnc/pull/3193

A new version is available in master:
github.com/LinuxCNC/linuxcnc/blob/0bc97e...nts/toggle2nist.comp

which you could install into your version by downloading the new version and using
(sudo) halcompile --install toggle2nist.comp

Note that 'halcompile' requires the 'linuxcnc-dev' package to be installed

Also note that people used to work around some of the problematic 'toggle2nist' behavior by adding hal components between the momentary switch and 'toggle2nist.in'. Looking at your .in pin signal in the halscope sreenshot makes me think that you might have done that. If you use the new version make sure to directly connect the momentary switch to the .in pin.