I need a simple CSP example for CiA 402

hi Rod,

I do not know which type of drivers you are actually using but for my configuration homing works normally. Everytime it starts and dones right. and repeatabelity is usefull too.. but it was pain to done it for my old hardware stuff..

I had customized Dominiks cia402 homing subroutine for my hardware and shaped them like in my regular PLC programs.. but you have to had a right servo homming subroutine setup inside the servodrive, right sensor or switching device type, right homing mode codes etc... 

code should be splitted to read and write function, but I do not have time to do it and because of them I added single scan time delay temp...

there is starting of homing subroutine for each type of drive different and therefore I am setting bit 4 or bit 11 in the controlword 
 

Ah, that helped a bit. Swapping your ECT60 generic config in for my ECT60 basic_cia config (and modifying pin names to match) resulted in slightly different errors and a bit of motion. It's only moving target-position by -50 before getting following errors, but it *is* moving.

I'm not sure quite what's up -- swapping back to basic_cia keeps the same behavior, so maybe I wasn't setting one of the 0x2xxx SDO entries?

In any case, I'm probably looking at a mix of missing per-drive config and maybe bad CiA 402 following limits. In either case, it's something that I can probably move forward on quickly.

Hi Dominik, 
​​​​​​You are talking about really nice stuff... I had lack of informations..about that mode things

If I am understand right, interpolation of more axis over ethercat stuff should be performed just in the CSV mode with PID stuff setted in the lcnc like with analog velocity -10 to 10V ?

Because of each one acc decc etc which are done during CSP via derivation of actual position? I do not know much about the problematic of drivers firmware but at high school we have learned about derivation 1st and 2nd of position and they are the velocity and acceleration(positive/negative)? They should be known? Or? But with scan cycle delay?

Please, tell us more about your experiences.

Thanks
​

FWIW, I think I finally found my problem: I had dcConf set wrong in one case and not set at all in others. It looks like RTelligent wants assignActivate=300 and the Leadshine 2CS3E-D507 wants 700.

I'm not a big fan of needing magic numbers from ESI files in order to get devices working, nor am I a fan of the way this fails if dcConf isn't set right, with the drive silently failing to move.

It looks like lcec_main calls ecrt_slave_config_dc *after* calling the per-device _init code, so adding a default dc_conf setting for CiA 402 drivers wouldn't be hard. Doing this generically would be hard, but hard-coding assignActivate=0x300 for the rtec driver, for instance, would be pretty simple. I'll start a new top-level topic in a minute.

Spent some time trying to catch up on your journey earlier today!
Ideally, if a value is defaulted to 700 or 300, it would be great if it could be overridden by a modParam.
I hate hardcoding stuff. Bound to catch you one day.

Made a bit more progress with RTelligent steppers in PR #393 .  It defaults to adding an implicit `<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>` if dcConf isn't provided.  If you want a different setting, then just provide it explicitly.

That's enough to get this to work:

I have a little bit more cleanup left; this defaults to mapping everything needed for CSP mode, but changing to anything else is kind of painful.  I'll go ahead and add a bit of code to make that easier, and then add explicit rtec support to lcec_configgen, so it'll add common modParams to generated configs.

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.

I'm guessing there is not an easy way to test how many PDOs a slave supports? Can we probe programmatically to work out the PDO capacity?
I guess a slave will just ignore PDOs that are more than the number it can accept?

There is not that many mandatory pins we need for linuxcnc. Keep it short. There will be no need for debugging once this is set.

It seems the ECT drives include the input pins as  part of the CIA402 space but the outputs are custom PDOs. Seems like the outputs should be left out?
Is there a parameter to include the Inputs?
Is there settings to configure homing?

Hmm, I thought I responded to this yesterday. Presumably the forum timed out on me and I didn't notice.

Inputs: they're enabled by default. There are modparms for all of the RT per-pin settings (homing, estop, nc/no, etc).

Outputs: according to `ethercat sdos`, RT steppers actually do support the CiA 402 outputs, but they're not in their docs. I have them enabled in `rtec`, but haven't verified them yet. I *suspect* that they weren't working due to distributed clock problems before.

Homing: all of the CiA 402 homing settings are available, but they're not part of the default set of pins right now. You can get them via extra modparams. Since no one really seems to know how to home via CiA 402 today, I figure we can circle back to it.

One thing I'm trying to get working at the moment is finding a way to expose some modparams to lcec_configgen without hard-coding device-specific logic there. Basically, I want to be able to tag specific modparams in lcec_rtec.c and have their name and a default value be visible to external tooling. The first pass on that is done, but it mostly just pointed out that I hadn't fixed modparams for 2-axis RTEC devices, so there's a bit more code to go.

The idea is that specific modules can say something like "the user will probably want to change this modparam, so show it in the autogenerated config", and it'll appear, with the default value, all automatically.