github.com/grandixximo/linuxcnc/tree/9d

This is phase 0 completed, according to my plan, this is extremely experimental work in progress, there are known issues at the moment, no arcs no blends, no scurve, as illustrated by the plan you can find at this post, which I got not much feedback..

forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=640#341856

Next phase it is IMO too hard to be vibe coded, but I will try in my spare time.

The issue with the original code was it was developed with a machine that homes to index so it does not work cleanly with home to sensor. The real problem  is that during device homing, Linuxcnc throws following errors because it has not commanded movement. What generally needs to happen is the position feedback is synced with commanded position so Linuxcnc is happy. This is why most working solutions also provide their own cia402.comp

Yes, I think homing can be standardized for cia402 devices and the new home comp is there now to support that. So much of homing.c becomes irrelavent with device homing so the homecomp allows control of what is needed. I've had a couple of goes at it. The first was obsoleted by a rewrite of the homecomp paradigm.

The cia402 state machine is actually very simple. very linear with the exception of error and safety steps to prior states. The flowchart here is a good resource
www.kebamerica.com/blog/comprehensive-gu...a-402-drive-profile/

Anyway, back on task. It occurred to me that I had included some standard PDO's that are not reported by Ethercat pdos. I will revisit that. 

 

Thanks for your reply @andypugh

I copied and pasted your suggestion into my HAL file, replacing the original erroneous text.

Unfortunately when launching Linuxcnc, an error is shown up as attached in the .png file.

Revised HAL file also attached.

Regards

Phil

I mostly run G64 P0.05 in metric, G64 P0.002 in inches, G61 is afterthought for us, but will be tested...

the on screen button and physical button cannot remain synchronized as the screen cannot physically change the mushroom buttons state. so you will need to add in some hal NOT allowing the UI estop button in probe basic to be in a state different from the physical mushroom button.

I use gmoccapy.

So far, I have found that these two signals control the feed rate:
gmocacapy.spc-feed.value
gmocacapy.spc-speed.value