help with ethercat and omron drives

Thanks. I need to do my IO and some fine tuning (servo tuning) and then I see about making a nice organised how to including files and what each line is for.



I need to figure out modbus spindle now. I hope that is easier to follow (I haven't looked at it at all yet)

Any luck on the "how to" and files you used to make it work?

I struggled with the linuxcnc-ethercat Omron slave type in the XML configuration, it seems highly dependent on the linuxcnc-ethercat version, so that is why I am really curious of your xml setup. Did you goto a generic type maybe for that reason? Even the example in the repo is incorrect or not up-to-date, I don't know what version type="R88D-KN04H-ECT" will work in. It should be type="OmrG5_KN04H".

Also for anyone reading if you want to enable DC sync its worth noting the difference in versions
refClockSyncCycles = "-1" for older versions of linuxcnc_ethercat ( i.e. lcec ) syncToRefClock="true" works for newer versions.

I mention this because if you scour ( like most of us ) the posts you will see many different flavors of xml files.

I used the linuxcnc ISO image version 2.9.3 and that has an older version of linuxcnc-ethercat.

Also the OmrG5_KNxx does not expose all of the PDO's available on that syncManager. So doing a generic and manually building it might be a better option. Supposedly the drive has variable PDO SM but I have no clue how to set that up.

Other lessons learned, DO NOT use the ethercat pdos info to setup your XML. For some reason some of those value can be incorrect. If you have access to the ESI files use that as the golden standard, that is available from omrons website if you goto the specific product page.

In case anyone was wondering I think I found the thread where i havenofish pulled the xml file from
forum.linuxcnc.org/ethercat/54975-omron-...s-synch-error#329216 by tpa58
It uses a generic type.
If anyone understands that xml and could explain it that would be great. I do not know how he maps to a fixed SM with different addresses, but it does seem to work. I still get some "unrelated errors" but that's probably more of my particular hardware setup.

Sorry, missed this.

Yes, that's where i started with the xml. I don't change much other then to make it specific to the 3 motors i have. My xml file is in my other thread here:  New ethercat / probe basic control for minimonster - Page 13 - LinuxCNC

Sadly no time to make a how too, but its on the list to go with the launch of the machine

Perfect, thank you, that helps me prove some of my suspicions. I have to dig more, seems like I didn't understand the Omron data sheet. Apparently you can select the PDO's you want mapped to SM 2&3, through some registers.

"The PDO mapping to be used is specified in Sync Manager 2 PDO Assignment (1C12 hex) and Sync Manager 3 PDO Assignment (1C13 hex)."

I would be surprised if you don't get "83" errors. I get alot of unmatched datagrams but it will go into "op" mode. It might have to do with the actual PDO assignment register.

Yours might work because you have different PDO's defined, however it also states:
"Since the mappings you changed are not saved in EEPROM, you must specify objects each time you turn ON the power of the G5-series Servo Drive in order to use the mapping other than the default setting."

I did not see any SDOconfig for those registers, so I will assume you have the "default" values, which I will confirm on my drive:

Drive Firmware version v2.14 ( ethercat upload -p3 --type string 0x100a 0)
My Default values are:
Sync Manager 2 PDO Assignment Register readings
ethercat upload -p3 0x1C12 0 = 0
ethercat upload -p3 0x1C12 1 = 0x1701
ethercat upload -p3 0x1C12 2 = 0x0000
Sync Manager 3 PDO Assigment Register readings
ethercat upload -p3 0x1C13 0 = 0x1
ethercat upload -p3 0x1C13 1 = 0x1b01
ethercat upload -p3 0x1C13 2 = 0x0000

So we can see the hal file you are using is incorrect.
Unless you set these up somewhere else, but I wasn't able to see it in the XML settings

yours have 0x1702 & 0x1b04 which are mixed matched, not sure if thats allowed. By default it should be 0x1701 & 0x1b01

Ah so the variable PDO mapping makes sense now. You can assign whatever PDO's you want, you set the Assignment registers to 0x1600 & 0x1A00 respectively. If I can get that to work I will post a xml file for that example as well.

Maybe this is documented already somewhere and I just missed it. The key to all of this is this magical argument in the slave tag
configPdos="true"
This actually does alot of what I described above, however, it works in the XML for "other" reasons. If you look at the dmesg log with "ethercat debug 1" you can see exactly what its doing. The XML is still incorrect. To truly use the configPdos="true" properly you have to use the variable mapped PDO's. The reason the XML "works" is because it sets the PDO assignment register to the address listed in the <PDO idx>, however you will get a bunch of errors because it will try to map the PDO's to read only registers. And you don't truly get a variable assigned PDO, you only get what is in the fixed PDO in the registers selected. So it could be intentional, but if you are going to use it, might as well use the variable mapped PDO so you can pick and choose exactly what PDO's you want. However, I think there is a caveat to this, variable PDO mapping is only available in Firmware version > 2.1. So this could be the "lazy mans" way of setting the Fixed PDO's for SM 2&3.

I get 83 errors when I shut down linuxcnc, but they reset when it turn it back on. So a non issue, although would be good to know the why and fix it.

Also not I have not yet set up the IO on the drives.

I think I have seen those 83 errors as well, probably some issue with how it starts/stops but I agree that should not be an issue. I might try that with the "built in" drivers to see if that behaves any better.
Errors that don't really cause any known issues on my end but I did fix is
<pdo idx="0x1702"> to 0x1600
<pdo idx="0x1b04"> to 0x1A00
That maps to the truly variable PDO mapping, the ones you have set are fixed PDO mappings, and when lcec tries to write to them it gets errors and writes them to the dmesg logs. In addition if you use the correct ones you can map whatever PDO's you want.
I am pretty sure with the xml file you used it does not configure DC sync. When I use the built in "driver" type="OmrG5_KN04H" I see a message about the DC sync, when I use the example xml it does not, which makes sense because its not enabled in master.

refClockSyncCycles = "-1" for older versions of linuxcnc_ethercat ( i.e. lcec ) syncToRefClock="true" works for newer versions.

For anyone out there trying to use variable PDO, for some reason my drive does not support 0x60f4. It took me a long time to figure that out.