CiA 402 in 1.15.0

I went ahead and merged the first pass at CiA 402 support, including an "rtec" driver for RTelligent ECT/ECR stepper drivers and a "basic_cia402" driver for semi-generic device support.  You can see documentation here:

• linuxcnc-ethercat.github.io/linuxcnc-ethercat/cia402.html
• linuxcnc-ethercat.github.io/linuxcnc-ethercat/rtec.html

They're not done, and I'm planning on making a few changes in the next few days that may lightly break users.  Call this "beta" at best, but I'd love to get a bit of feedback, especially if people are willing to give "basic_cia402" a quick spin.

At this point, I'm able to drive an ECT60 in either position or velocity mode using either type="ECT60" or type="basic_cia402".  Using the ECT60 driver gives you more modParams and pins, covering things like open/closed mode, motor current, current torque, current RPM, and so forth.  See the docs.

Right now, digital in and digital out ports aren't working correctly on my ECT60, and I'm not quite sure why.  I think it's a hardware problem -- using 'ethercat upload' gives weird results, too -- and it wasn't worth delaying over.

This should support pp, pv, csv, and csp modes today.  I haven't made any attempts at homing mode, interpolation mode, vl mode (for VFDs), or either of the torque modes.  It's designed to work with the existing cia402 HAL component.

Coming up soon, I'm hoping to:

• Move a number of the generic CiA 402 modparams (profile velocity, profile acceleration, etc) to be pins instead.  They should have been pins in the first place.
• Figure out my digital in/out aren't working, then add generic digital in/out support into the CiA 402 library.
• Fix the mess that is "pdo_entry_count".  It's surprisingly hard to know how many PDO entries you're going to need to register ahead of time, as almost everything in the CiA 402 spec is optional.  At this point, I've added error reporting when a device requests N PDO entries, and usually just end up changing the count until the errors stop.  It's probably time to make it dynamic and delete "pdo_entry_count" across all drivers.
• Add homing
• Add interpolation mode
• Add vl mode
• Finish multi-axis support.  The framework supports up to 4 axes in theory, but there are a few details still missing, and I don't have any multi-axis hardware to test with.  Both Leadshine and RTelligent make dual-channel stepper drives; I'm hoping to pick up one of the Leadshine models after lunar new year.  Also, I should extend this to 8 axes, as per the actual spec.
• Look at migrating some of the semi-CiA 402 drivers in the tree to use the new CiA 402 framework.

After that, I may look at extending the cia402 HAL component to cover a few more modes.

How come you have 42 posts and 45 "thank you" ?
Again, thank you.

Great work Scott.
on the ECT60, The digital inputs are at 60FD per your documentation. Here is how I defined them
github.com/rodw-au/linuxcnc-cia402/blob/main/ethercat-conf.xml

But Rtelligent does not have any listing in their manual for outputs in the CIA402 workspace. Instead they are in the manufacturer's space at 
204A
github.com/rodw-au/linuxcnc-cia402/blob/main/ethercat-conf.xml
I assumed that outputs were not part of the CIA402 standard.

I'm sure it won't be hard to get inputs and putputs into your driver. Hope this helps

Yeah, outputs are listed in the standard as being at 60fe, and `ethercat sdos` shows that the ECT60 has them there, but weirdly it doesn't appear in the manual. I'll figure out what's up soon enough.

I'm currently removing `pdo_entry_regs` from practically everywhere in the codebase and replacing it with a thin wrapper inside of `slave` that tracks the number of defined PDO entries per slave, and then code that merges all of the slaves' entries per master at the end. This will let `basic_cia402` do things like ask the CiA 402 device which modes it supports and then create the right pins at runtime, that's all but impossible today.

This ends up removing *so* much boilerplate code and ~3 different hacks for variable numbers of PDOs, only one of which was mine .

And the output port functions are defined in 2005

 

It would be good to get outputs working because the alarm output should be connected to joint.N.amp-fault-in 
I guess in the absence of a brake, the other pin gould be used as a generic output

 

Thanks. I have those already, as <modParam name="output1Func" value="brake"/> and so forth. There are a lot of modparams here .

I had output1 working, but output2 wasn't, and none of the inputs worked, even with "ethercat upload" for reading the PDO values directly. I probably just mis-read the wiring colors or something. I'll get back to it in a day or two.

I just merged the dynamic PDO allocation change; that hit 97 files (!), but most of those were just automated changes. As of 1.16.0, there's no reason to bother counting PDO entries directly anymore. Just call lcec_pdo_init() and everything will be resized correctly under the hood. This had a lot of nice consequences in the code.

Everything compiles cleanly and all of my tests pass, but I can't test everything. The AX5xxx and FSoE devices had the most invasive changes, so they're probably the most likely to have problems.