EtherCAT IO and frequency counter for plasma cutter

Here is my latest EtherCAT card, the EaserCAT 6000, with 12 digital inputs, 4 digital outputs, and one frequency counter input for THCAD output.
 
It's the one down in the corner. There are three RTelligent ECT60 EtherCAT stepper motor drivers as well.
The inputs are limit switches for X, Y, Z, e-stop, floating, break-away and arc-OK.
Plasma-on is controlled by output 1.
There is one frequency counter input. Come to think of it it wouldn't be difficult to add another frequency counter for ohmic sensing, but I don't think my plasma cutter supports that, a Herocut 55X.
More details are here, including all schematics and source code.
github.com/MetalMusings/MyOwnEtherCATDevice
I haven't been cutting a whole lot with it yet. The worry has been the frequency counter that had some interference, seems to have been due to poor cable choice. With that sorted, voltage reading is now stable and THC works just fine.

Very cool, Are you using internal homing and limits on the drives?
I finally worked on a homing component for the ECT60 over the weekend but have not got as far as connecting up a hal file to it. I ran out of energy!

I decided to go back to basics and control the homing using the Ethercat pins direct. In fact I added a bunch of pins because I did some work previously before the current homecomp was released. I'm sure there are a bunch that need deleting once I get it working. Long term I'd like to get rid of the cia402 component. I'm not sure if I can do that in a home comp.

Have a look. any help appreciated
github.com/rodw-au/cia402_homecomp

No, not internal homing but I did get the following error issue when starting up.
I reckon it is the encoders that aren't starting at zero. At least when they have been running and restart QtPlasmaC, linuxcnc expects pos-fb to be zero, but the motors are where they are which is not zero usually. Also when the motors are enabled they move slightly.
I did two things for that
1. Zero the encoder just before starting by adding a startup commandNo encoder feedback on Z.

2. During the first five seconds after "machine on" there is a much larger following error limit, then it goes down to standard following error limit.
Used the timedelay and the ini component for that.

Strange, I have never had that issue. Recently after a long holiday without touching it, I could not get it to move at all and it made awful sounds.
I fixed this by resetting to factory defaults (0x10110) by changing the values in the XML on sucessuve restarts. Now its perfect so I want to work on homing,
The only following error I had on my Mill with ECT86 drives was when I had the accelleration too high and it would do that coming out of homing. I decided this was probably because the accelleration (well decelleration here) was too high and the setting was overcome by inertia. Reducug accelleration in the ini file fixed it.

But what settings have you entered? I have max current, standby current and closed loop/open loop. Everything else is default.

I realize my method is a temporary fix. Maybe I can look into that now when things work fine. On the other hand, if it works it works.

I have homing on traditional limit switches. Seems to work so I am happy.
 

Yes, it was weird because I have already built a machine with ECT86 drives so knew what was needed.
I have used a few more sdos for homing parameters (5 sdos) and also to configure inputs for homing and estop