Default dcConf settings for CiA 402 devices

More
30 Mar 2024 22:38 - 30 Mar 2024 22:40 #297240 by scottlaird
I just spent *way* too much time debugging a multi-device CiA 402 problem, only to discover that I was doing distributed clock configs wrong in my XML file because I didn't really understand it.  Of course, we don't actually seem to have any documentation on correct values for dcConf anywhere, so I had to spend an hour or so researching the topic.

It looks like neither RTelligent nor Leadshine CiA 402 devices will work in CSP mode without distributed clocks enabled properly.   To review a bit, this is controlled by the per-slave <dcConf> tag in our XML file, which has 5 parameters:
  • assignActivate
  • sync0Cycle
  • sync0Shift
  • sync1Cycle
  • sync1Shift

After digging into things, it looks like assignActivate should simply be set to whichever value is recommended in the device's ESI file.  Generally, this will be either 0x3xx or 0x7xx, and xx will be 00, 10, 20, or 30.

sync0Cycle seems like is should pretty much always default to "*1", which is our servo time period.  It's possible that really unusual hardware will want a different value here, but "*1" seems pretty sane as a default.

sync0Shift seems to vary widely in sample configs, but I suspect that 0 would be fine most of the time; this shifts the sync0 interrupt by some number of ns, which presumably reduces jitter slightly.

sync1Cycle and Shift are basically the same as sync0, but not all devices use sync1.  Ones that do sometimes set it to "*1" and sometimes to a small multiple like "*3", for every third servo cycle.

Given all of this complexity, is there any reason not to set dcConf by default in device-specific CiA 402 drivers?  For instance, I have a driver for RTelligent stepper and servo drivers.  Every single RTelligent device that I can find an ESI for says to use 0x300 for assignActivate.  So, if dcConf isn't explicitly set, I can add an implied <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0" sync1Cycle="*1" sync1Shift="0"/>.  It's possible that we don't want sync1 set, or want it set to a multiple of the clock time, but that's easy enough to handle on a device by device basis.  I'm not going to do this for unknown CiA 402 devices, but we can probably capture the bulk of known devices pretty quickly.

Anything that I'm missing here?  Is there anything subtle with shift times?

I'll go ahead and add all of this to the LCEC documentation soon.
Last edit: 30 Mar 2024 22:40 by scottlaird. Reason: fix formatting
The following user(s) said Thank You: tommylight, rodw, Pro_El, foxington, tiagounderground

Please Log in or Create an account to join the conversation.

More
01 Apr 2024 00:19 #297315 by scottlaird
A bit of quick data from my pile of ESI files:

Somewhat surprisingly, 0x730 is the most common AssignActivate value for devices, followed by 0 (DC disabled).

Somewhat oddly, there are no 0x710 and very few 0x310. Surprisingly, there are a few 0x1xx entries, plus a few devices with 1, 0x301, or 0x30, none of which looked valid when I read the spec.
   1468       assignactivate: '#x730'
   1444       assignactivate: '#x0'
   1312       assignactivate: '#x700'
    834       assignactivate: '#x300'
    288       assignactivate: '#x320'
     84       assignactivate: '#x100'
     24       assignactivate: '#x1'
     15       assignactivate: '#x120'
     13       assignactivate: '#x301'
      9       assignactivate: '#x130'
      6       assignactivate: '#x30'
      5       assignactivate: '#x310'
      4       assignactivate: '#x720'

To recap, the high-order byte (the leading digit in 3-digit representations, so the 7 in 730) is which syncs are active. 0 is none. 1 looks like "DC mode enabled". 2 is sync0, and 4 is sync1. Add those together to get the value, so 3 is DC enabled, sync0 enabled, and 7 is DC enabled, sync0 and sync1 enabled.

Practically speaking, none of the "weird" values matter to us right now. Interestingly, most of them are from Beckhoff; there are a couple EL7xxx devices that have odd values listed for non-DC modes, and some of the communication modules are generally weird, but (most importantly) I don't see any devices with multiple *different* 3xx or 7xx values. So I can probably grab the 3xx/7xx values and drop them into the ESI summary lurking in GitHub and then find ways to get the right value from that automatically in some cases, maybe as part of lcec_configgen.

Please Log in or Create an account to join the conversation.

More
01 Apr 2024 20:45 #297396 by scottlaird
Next question: is there any reason *not* to set up DC for devices that support it?

Specifically, if `lcec_configgen` sees that device XX:YY is listed in github.com/linuxcnc-ethercat/linuxcnc-et...ster/scripts/esi.yml, and has a non-zero AssignActivate value, should I just go ahead and add a tag to the generated config?

The list includes a number of modules that I wouldn't have expected to use DC, like EL31xxs and most of the EL4xxxs. I don't *think* we want to enable DC silently for devices where we work without it, but should we add it explicitly?

Please Log in or Create an account to join the conversation.

Time to create page: 0.098 seconds
Powered by Kunena Forum