Advanced Search

The Problem is the same as before.

@Aciera
So I did halcompile --install toggle2nist.comp.
I see a new pin toggle2nist_1.debounce so the update should be OK.
I also put the pause/resume signal direct to the toggle2nist without the toggle in front.

@andypugh
I dont understand "output pin from hal_input" my input pins from the gamepad are input.0.btn-base6 ...

You can try downloading the .deb file directly and manually installing.
(sudo apt-get install ./deb-filename )
The ./ is a clue to apt-get to look at a local file rather than on the repository.

It looks like Trixie has a more restrictive archive key policy than Bookworm, and it's going to take me some time to work that out as it's a subject I know next-to-nothing about.

www.linuxcnc.org/dists/trixie/

"align-pin" isn't a physical pin (or, rather, it _can_ be a physical pin, but which one it maps to is dependent on mode)

In the step counts case:

github.com/LinuxCNC/linuxcnc/blob/master...s/carousel.comp#L292

And I am somewhat concerned that I have made an error there, as I don't think that the % operator will return a negative value.
I can see what my code was trying to do, but I suspect it doesn't do it.

Do you know what your counts (and scale) were at the point that the system got stuck?

I checked the link you provided and find the note on page 16 interesting: "... This index 0x2001 only works on ECR60. If you change it on ECT60, please find index 0x2020..."
The developer of my code intended it to be loaded into an ECT60 (closed loop) driver and configured it for an open loop stepper. Given the above statement (if true), it's odd that he sets up register 2001 but not register 2020.
<sdoConfig idx="2001" subIdx="0"> <!-- segmentation/resolution for open loop -->
            <sdoDataRaw data="40 9C" /> <!-- 40000 counts/rev -->

"For fun", I tried adding this back into ethercat-config.xml, but the error condition remains.

I looked into downloading the package onto my Windows PC but it's unclear which download to use. They have quite a few and the link just goes to their front page, not to a specific download screen. To be honest, I don't hold out much hope that dropping it in place of my config file will make it work, but as you alluded to, perhaps it contains something the manual left out. Anyway, their comment above makes me wonder all the more whether there is key documentation missing from the User Manual regarding differences between the ECR and ECT drivers... sigh.
 
 

Another possibility is that pressing two buttons means that the button-release event is not seen. So check the output pin from hal_input too.

The logic for setting that HAL pin is here, it just reports the system state:
github.com/LinuxCNC/linuxcnc/blob/master..._intf/halui.cc#L2167

Is halui.estop.activate being driven at all? Is it false?

I was upbraided earlier by a friend from the Motor Club about this, as he watched your video and thought that I should have defaulted to a 55 degree angle as anything other than Whitworth is an abomination.

Adding the compound angle wouldn't be too hard, but I doubt that cutting buttress threads is that common, and you can always MDI the G76 directly if you need to.
I think that 29.5 is "not terrible" for Whitworth, but I would need to sketch a diagram to be sure. It's probably not ideal for BA threads (47.5 degree) or Panzergewinde (80 degree)

I also suspect that the macro takes many more passes than strictly necessary,

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.

I have this gamepad.hal as an example for my problem.
This is used with the button of a gamepad.I start a program by a button, then I can pause/resume it by another button.The third button is to stop the program.
The problem I have: If the program is started and I press pause/resume and stop at the same time, sometimes the toggle2nist_on get stucked in on state and the pause/resume will not work until I quit linuxcnc and start again. Is this a known behavior, or is something wrong in my gamepad.hal

Do you have the errors from syslog?

I would like to see the 60fe and 60fd sdos and pdos out specifically and only the 6 mentioned PDOs in there.

Here is a document on how to use the drive in TwinCAT.
shopcdnpro.grainajz.com/category/409767/...%8D%97-%E8%8B%B1.pdf
I guess it is worthwhile to check it works there.

there will be a meeting in Stuttgart again.
nuudel.digitalcourage.de/dGtDlt4Tzw9tZ3Hn