I'm trying to figure out what the best user experience is for CiA 402 devices with specific drivers, like the RTelligent EC* devices.
Specifically, what do we need to do to configure them for various CiA 402 opmodes, like CSP, CSV, and so forth. In an ideal world, we'd just map all of the PDO entries that the device can support, but a lot of devices don't have PDO space for this. My Leadshine driver, for instance, only really has room for 8 TX and 8 RX PDO entries, but supports about 40 different CiA 402 CoE objects. We can't map them all at once.
RT is a bit better than Leadshine in this regard (IIRC room for 12-16 entries *and* fewer optional features), but I still doubt that there's room for all of them.
With the `basic_cia402` driver, I handle this by having a *huge* set of `enable*` modParams. The `lcec_configgen` tool probes `ethercat sdos` and writes out the full set of `enable*` settings that each device supports, but this frequently needs to be edited down in order to keep under the device's (frequently undocumented) PDO size limit. So, getting basic_cia402 working requires some editing.
With device-specific drivers, I think we can do a bit better. First, we can default to CSP (for most things) or VL (for VFDs), with a reasonable set of additional PDO entries mapped. For devices with large PDO spaces or a small number of objects, we can just map everything and be done.
For the rest of our devices, I'm leaning towards overriding the `enableCSP`, `enableCSV`, `enableCST`, `enablePP`, etc modParams. Normally, these only enable PDO entries that are a hard requirement according to the CiA 402 spec. So `enableCSP` adds `actual-position`, `actual-velocity`, and `target-position`, but not `position-demand`, `velocity-demand`, `torque-demand`, `actual-voltage`, or any of a handful of other useful-for-debugging pins. That's because we can't depend on any random device actually supporting any of the other PDOs from within generic code. But, for device-specific drivers, we should know what's available. So we can override `enableCSP` and friends to enable a set of additional PDOs that may be useful. If you're building a device that could use CSP and CSV, then you can say `enableCSP` and `enableCSV`, and you *should* have everything that you need mapped, although there's a chance that you'll overfill your PDOs. If that happens, that you can still do things like `<modParam name="enableTorqueDemand" value="false"/>` to take more control. We'll need to document this and file it under "advanced use", but we can probably make most of the normal cases pretty easy to use correctly.
I'll ignore the issue with the cia402 HAL module only supporting CSP and CSV and not allowing switching between them in realtime mode for now. That should be relatively easy to change if we ever need to.
