Delta ASD-B3 support

[zmrdko]

Hi, I went through the issues and I found out, that you recently added support for A3 drives. I have B3 drives which should be etherCAT wise similar if not the same as A3 drives. Should I just go ahead and test it as A3 drives or not? @GuiHue is this the working config: https://github.com/GuiHue/linuxcnctests/tree/main/ethercattest ?

• i see now its conifg with cia402 linuxcnc component

[zmrdko]

I tried cia402 linuxcnc component and it works, but I am missing input pins in linuxcnc, which should be available using deasda.

[GuiHue]

@zmrdko I don't have any B3 and have only briefly glanced at the manual. It looks like the Ethercat registers are identical. What will be different is the PID. According to the EtherCATInfo Files by Delta Eletronics it should be x00006080. Can you verify this using ethercat slaves -v

Another defining feature is the resolution of the internal encoder. That appears to be 24bit (16,777,216) by default. For every other case this can be setup using HAL from LinuxCNC.

If you can provide confirmation, I'll see to adding those aspects during the weekend. Keep in mind that the driver currently does not expose things like IGBT temperature or DIO status. I will look into this at a later stage.

Regarding the Configs in my Repo: I have pushed my latest tests this morning. However, this is not documented for general public use. You'll have to work through the files yourself. The folder contains multiple minimal configurations and hence a bunch of XMLs. For the recently added driver to master (not released yet) you may want to look at files starting with ethercattest-A3-new-CS%

CIA402 with the generic driver can be found here: ethercat-conf-A3CSP.xml

[zmrdko]

you are correct.

it is possible to use old b2 motors with b3 drivers, but b3 motors have same resolution as A3: 16777216 pprev.

however due to size of my router I am using E-gear to scale down, since the 32bit integer was too small for full resolution.

[GuiHue]

Same applies to A3 with A2 drives (which is what I do). For this, the factor can be changed. See repo above.

[scottlaird]

FWIW, I just added the A3 and B3 ESI file to my ESI collection. Something isn't quite rendering correctly on the index page, but you can see the A3 here:

https://linuxcnc-ethercat.github.io/esi-data/devices/ASDA-A3-E+CoE+Drive

Notice that it thinks that the A3 and B3 have identical PDOs.

[scottlaird]

Okay, the index was just a caching issue, and I went ahead and added the A2 as well.

Finding Delta's ESIs is a bit of a pain, but not as bad as Bosch Rexroth, which seems to require reverse-engineering their Javascript, or a few other manufacturers which only package them inside of their TwinCAT equivalents.

[scottlaird]

I was going to suggest using the new class_din / class_dout code for digital pins, but it doesn't look like the A3/B3's pins actually match the model that they're expecting. Delta provides a 32-bit integer with all of the pins crammed together. I should probably just extend din/dout to handle this case, but it won't happen today.

[GuiHue]

I guess hardcoding is easier in this case. Could be changed over eventually.

[GuiHue]

I have added B3 and the DI pins (read only) as well as torque (instead of current - both are relative values anyways and are directly proportional). Handling the DO is generally possible, but also requires the drive to be configured in its parameters. I have not yet addressed that and probably won't for the time being.

[zmrdko]

https://github.com/zmrdko/3dworks_ethercat_lcec just a quick test. I was able to jog, didnt play with gearing, etc

Great job!! Thanks!

[GuiHue]

Guess we can close this ten?

[zmrdko]

Right!!

[zmrdko]

@GuiHue, please do you have working config for homing using Delta drive?

[GuiHue]

@zmrdko Unfortunately I do not as I am not using that function. I rely on linuxcnc for homing as I also use it to handle gantry homing. I am aware of the fact that this can be done using onboard DeASDA functions but since the other mode is working well for me, I have opted to not go down yet another rabbit hole.

[zmrdko]

I am experiencing unreliable switching to OP mode from PREOP. Most of the times first drive does not wake up.

my config is here: https://filebin.net/knuv8zfyajsi0r1w

any ideas how to debug this?

[zmrdko]

Florian Pose from EtherLab pointed out that I have issue with distributed clock:

https://gitlab.com/etherlab.org/ethercat/-/issues/104

He stated, that I have configured my drives with distributed clocks, but I am not sending any synchronisation datagrams. Why is that with my original value of refClockSyncCycles = 1000?

After short googling, I decided to change the value to -1 (1 works as well) the problem seem to be gone, but I dont know if this is correct setting.

From what I found in documentation here, it should be how frequent the distributed clock is resynced, but further explanation is missing.

Does 1 means the clock is resynced every cycle? Isn't that unnecessary?

Thanks

[scottlaird]

I don't know the answer, and I'm kind of hazy on distributed clocks right now. I'll see what I can figure out.

[zmrdko]

It is probably hardware issue:

so no more than 1kHz cycle time on raspberry pi 5.

[scottlaird]

I'm going to go ahead and re-close this since I think everything that we can do is working.