EtherCAT: How to use the dedicated OmrG5 lcec driver?

Unfortunately the driver currently only supports cyclic synchronous position control (and I will not have time to look into extending it any time soon).

You'll probably have to configure the drive for cyclic synchronous velocity mode (0x6060 <- 9), and setup the "Sync Manager" in the drive for some PDO mapping that contains target and actual velocity (e.g. 259th PDO: 0x1C12 <- 0x1702, 0x1C13 <- 0x1B02).

See the G5 EtherCAT User's Manual, sections "Sync Manager Communication Objects" and "Process Data Objects".

You cannot do this with the OmrG5 driver (not without doing some coding at least), so unless you want to & can code you'll have to set it up as a "generic" device in the ethercat xml file (type="generic"). I'm not sure on the exact details; better ask in the "Ethercat HAL driver" thread.

Here's an example .xml file that should give some clues at least: github.com/sittner/linuxcnc-ethercat/blo...ex/ethercat-conf.xml

@arvidb

Awesome... once again, thanks for doing the G5 as you saved me a lot of work down the road. Super glad Sascha accepted your pull.


Robert

I'm playing around with this driver a bit. It's pretty lacking today: only position control and only the default PDO mapping.

I want to be able to set up the drives for both positioning (cyclic synchronous position mode, csp) and for spindle duty (cyclic synchronous velocity mode, csv). I also want to be able to feed-forward speed and maybe torque to the drives, and I want feedback of velocity and load as well.

I understand how to set up op mode and change mappings technically (e.g. what needs to be sent on the EtherCAT bus to set up the drive and also how to modify the source code to do this) - I've tried it and it seems to work. My difficulty is how to design the user interface: how to best specify in the xml file what mode of operation to use, which objects to map into the PDO and how to connect them to HAL pins. A discussion about this here would be great!

There are multiple things to consider, but first some technical background:

The drives are set up by specifying the mode of operation (csp/csv/cst) and the objects to map for cyclic data transfer. The slots and size of that data are limited: a maximum of 10 objects can be synchronized in each direction (send and receive) and the maximum sizes are 30 (Tx) and 24 (Rx) bytes.

Available Tx objects (# of bytes and name):

1 Sysmac Error Status
2 Statusword1
2 Sub Error Code
4 Reference Position for CSP
2 Error code
2 Statusword
1 Modes of operation display
4 Position demand value
4 Position actual internal value
4 Position actual value
4 Velocity actual value
2 Torque demand
2 Torque actual value
2 Touch probe status
4 Touch probe pos1 pos value
4 Touch probe pos2 pos value
4 Following error actual value
4 Control effort
4 Position demand internal value
4 Digital inputs

Available Rx objects (# of bytes and name):

2 Coordinate System Setting Mode
4 Coordinate System Setting Position
2 Controlword
1 Modes of operation
2 Target torque
2 Max torque
4 Target position
4 Max profile velocity
4 Profile velocity
2 Motion profile type
4 Position offset
4 Velocity offset
2 Torque offset
2 Touch probe function
2 Positive torque limit value
2 Negative torque limit value
4 Physical outputs
4 Target velocity

There's a lot to choose from and any fixed mapping would be quite limiting. So some way to choose what to map from the xml file would be great.

Many of these pins need special handling, e.g. digital inputs and outputs map to multiple HAL pins each; many of the pins needs scaling (to get position, velocity or relative torque) and conversion to/from float. Statusword and Controlword must always be mapped since they are part of a state machine that takes the drive from Pre-OP via Safe-OP to OP and back, controlled by the enable HAL pin.

So just using halType="complex" is messy and not really feasible. And the existing modParams mechanism only accepts HAL type arguments. Besides, wouldn't it be great if we could standardise the pin names for as many pins as possible (pos-cmd for target position etc.) rather than everyone specifying their own pin names?

So how would you want the xml file to look/work for EtherCAT servo drives? Here's a suggestion, please comment/write your own! Anything missing, anything that could be done better?
(linuxcnc-ethercat supports neither variable numbers of mapped objects - each driver has a hard-coded number of objects - nor slave-specific tags at the moment, so it would need some invasive work. But it is doable I guess.)

Hello,

the drivers don't need to have hard-coded number of objects. If you take a look at our stoeber5000s or the Beckhoff AX they have an variable design. You can define one or two Axis, add an second external encoder, add Submodules like Safty Cards FSOE.
This can all be done from the ethercat_conf.xml with corresponding Parameters.
Of course this has to be hard coded in the driver, also you can add additional pdos to an node from the config_xml like with the generic driver.

The advantages for the coded drivers to the generic ones, are that you can add function in the driver like CAN state machine, scaling or encoder handling to get the Halpin interface more linuxcnc friendly.

github.com/steup-engineering/linuxcnc-et.../src/lcec_nanopd4e.c

this is an driver for an CoE Drive with the possibility to change ModesofOperation at runtime between Profile Position, Profile Velocity and homing Mode.
PDOs are hard coded, but this is only for our internal use...

if you take an look on this:
github.com/sittner/linuxcnc-ethercat/blo...r/src/lcec_stmds5k.c

This is an example for passing parameters from the conf.xml to the driver for modularity. (line 224,229)

Cool, thanks! I was hoping to get a reply from you. Will take a close look at those files.