More advanced EtherCAT setup questions

 
Now that I've got my basic setup running, I'm looking at the more detailed setup, and have a few questions.

How are people monitoring that all the EtherCAT devices are still connected?
I've been testing, and if I simply unplug a cable or power them off, no immediate fault is generated. LinuxCNC only finally disables when I try moving an axis due to a following error. Is there some form of pin available that will detect if a device(s) have lost communication?

Is anybody reading the status from drives during operation?
I know I could connect the drive error variable to a suitable HAL pin. but is anybody also reading the error code?

I know that the last two questions are probably as much GUI based, but I'd be grateful to any pointers on how these things can be implemented.

Most drives have an error output. What happens if you monitor that? Normally you would send it to joint.n.fault-in can't remember if its NO or NC.
But what about monitoring a normal stepper drive or a Mesa card. Isn't the same risk there?

mwc wrote:

 
Is anybody reading the status from drives during operation?
I know I could connect the drive error variable to a suitable HAL pin. but is anybody also reading the error code?

 

Check your xml file - it may already have a fault status hal pin 'baked in'

And cia402.comp has a drive fault pin:
If you can unplug or power off your drive and LCNC doesn't error out immediately, your setup could use some work.  Do you have anything connected in HAL to joint.N.amp-fault-in?

I've just spent some time buried in the linuxcnc-ethercat documentation, and I think I have a solution to my first question.

lcec.0.slaves-responding gives the current number of slaves active, so I'm guessing I can use that via Classic Ladder to monitor for any major failings, and trigger a suitable warning?
I should be able to pull the basic Error status from the controlword, but it'd be nice to pull the actual error code without having to open a cabinet to look at the drive (on the nice to have list!).

My main concern is that LinuxCNC loads up without any warning if the drives aren't powered up, or the CAT cable is unplugged, and the first that you know there is an issue, is when you try moving an axis and get a position error. I like to cover most common eventualities when retrofitting/building a machine, so a basic sanity check of all the slaves being online I think is quite essential.


Something I've found missing from the linuxcnc-ethercat documentation, is a more general overview of the XML, as although it goes into good detail on specific functions, I can't see anything about the more general function of blocks. Like why are there 4 syncMaster blocks, yet the first two are empty (and required by the Lichuan drives!)?

For example my current question is how do I configure the drive current during initialisation?
I should really write a driver* for my Lichuan CL3-E57H drives, but even looking at the drivers for other drives, I'm not sure where that setting would fit into the XML, as I can't even find an example where somebody has set the current.
I'm fairly sure it shouldn't be in the syncManager/PDO block for the 1ms updates, but where does it go?


*I'd be willing to write a driver, but it would probably need the existing Lichuan driver renamed, as from a brief look at it, there is a bit more difference than just 4x the number of axes, as the xL3 drivers have more IO, so I think for simplicity, keeping the drivers separate would provide cleaner drivers for both.

spumco wrote:

<snip>

 

 

Just had a quick look, and drive error isn't currently collected, but I can add that.
I already have a line to check amp-fault-in, but having just checked in Halshow, drv-fault remains unchanged if I unplug the drives.

mwc wrote:

Just had a quick look, and drive error isn't currently collected, but I can add that.
I already have a line to check amp-fault-in, but having just checked in Halshow, drv-fault remains unchanged if I unplug the drives.

Maybe see if there's a drive parameter you can adjust which defines what the drive considers a 'fault.'

I would think that a drive would default to 'faulted' if it gets unplugged, but who knows what drive programmers think?  It could be that the default setting is 'fault' only gets asserted if there's an internal following error or under/over volt condition.

If you really wanted to lock it down you could try using the comp component with your lcec.0.slaves-responding against the expected number of slaves (eg set with setp). Then if you used estop-latch to manage your estop (which you should be using anyway), you could add an additional estop-latch in your estop chain so the machine could not be enabled until all slaves report in.

@spumco I think the underlying functionality (i won't say issue, as it's probably intended functionality) of drv-fault is in the lcec component, as once the drives unplugged, the drive can't really report a problem, and they don't trigger an error if communication is lost, they simply go idle.
I'm assuming the drv-fault only triggers once the drive actually errors, but I've not found an easy way to get the drives to fault yet, although i did just think about how to do it without risking blowing one up.

@rodw that's the kind of thing that I'm aiming for.

I haven't read deeply in to lcec component, but I wonder if there's a polling process to check for changes.  I'd be interested if drives change state on some parameter if they're disconnected.

spumco wrote:

I haven't read deeply in to lcec component, but I wonder if there's a polling process to check for changes.  I'd be interested if drives change state on some parameter if they're disconnected.

Looking at the ethercat documentation, the main parameter I can see is lcec.<m>.slaves-responding, which does what it says.
It doesn't appear to refresh that quickly, although that may just be that Halshow is slow to update.
I'd guess should a slave disappear during motion, a joint following error is likely to be triggered quicker.