Ethercat HAL driver

Hi Frank please send me your Twincat 3
project file
I am understand my estun drive init command in twincat...Thank you.

Best regards.

@ reid

If you see the amp in pre-op and you can't bring it in to the op state
my guess is that you are not setting the control word pins to switch the amp on.
Its hard to say without seeing your hal file...
For example Delta Ac Servo's require that the control word is set as
step 1) 0x06
step 2) 0x07
step 3) 0x0F
to move through the states into the final op state.
It's not obvious in the example configurations but by setting the pins in Hal in that order( or whatever order the amps you are using wants.), the amp turn on.

You also have to make sure that the mode is set e.g. CSP, CSV, homing etc. By adding the mode word to your pdo entry, you can set the bits in Hal or you can set the mode via an sdo entry directly.

Kind regards,
Dan

grotius:
thanks for the nice code. I'm not sure why you used IDNs instead of SDOs, though. (I'm not sure about much!)

sqmathelete:
I'd tried the mode-set and x06->x07->x0f trick, but it didn't seem to work.
I tried it some more, and found that if I set the mode before setting up the PDOs and the control sequence, my servo becomes enabled and I can control it with sdo downloads. It stayed in PREOP mode, though, and dmesg gave the same error about LRW and working counter.
I tried to enter OP manually: stdout was silent, it stayed in PREOP, and dmesg showed: I need to think about this...
Thanks,
Reid

Hello Reid,
the servos of the series beckhoff AX5000 need every time they connect to load all the configuration of the servo drive and servo motor through the IDN parameters.
I do not have this type of servodriver, but if it stays in PREOP it is because some parameter is incorrect, I do not know if you can look at the error in the servo driver to see where the problem is, I recommend that you go from parameter to parameter until you des is wrong, another thing you can look at is if you have loaded all the configuration of the servo drive with SDO parameters? I attached a file that uses PRONET servos and see what differences there are, I hope I have helped a little, regards
Chimeno

Hello again.
I've been trying hard to follow up all your tips, and I am here to tell you that trying didn't used to be this hard.

I have, you'll recall, a problem getting my ProNET servo online, and I've come to you for help.
Before I tick off some of the things I've tried, let me ask 2 simple questions:

Is it normal that, while lcec is running, the ethercat commands for up- and download 'hang' until lcec is terminated, while "ethercat master, slave, cstruct, and pdos" run immediately? I was a little surprised.

Also, it would appear that, as long as the slave is powered up -- both while lcec is running, and while it's not -- the frame count from "ethercat masters" is increasing at about 1000/sec. I thought cyclic frames were only produced while a master is active. Is this normal?

With that out of the way, let me guide you through some of the things that didn't solve my problem:

Dead end #1: do it the way they tell you to do it.
I adapted the pronet xml from chimeno and used it to load the generic driver with a freshly-powered-up slave. See the attachment pronet_2.xml.
I started up lcec with this hal fragment: The slave stayed in PREOP.
Plenty of hal pins were created. All the pins sourced from the slave are false or zero.
I did 'ethercat -p0 states OP' and it ran silently, but the slave stayed in PREOP.
I did 'ethercat -p0 pdos' and it listed an empty configuration: dmesg reports: The first group of messages happens only when the slave is powered on and is probably normal ?
The next group happens when lcec starts up.
I'd done most of this before my first post, so not much of this is new.


Dead end #2: bash it into submission.
Using a freshly-powered-up slave and a bash script (see attachment pronet_2.txt), I did ethercat downloads to configure my slave before starting up lcec. This includes setting the MODE and providing the 6-7-F startup sequence.
Before starting lcec, the pdo configuration set up by the bash commands "looked good to me" and seemed to match the values used in the hal xml in dead end #1. The motor actually turned on after the bash script, and I could control it with SDO downloads. (My wife was not impressed.)
ethercat -p0 states OP worked, but the drive reverted from 'run' to 'standby' when it went to OP.

I started up lcec while the slave was already in OP state, using the same generic xml as in dead end #1 (never mind that the xml and the ethercat commands are mostly redundant)
The slave stayed in OP mode.
The LINK light went to 'continuously on,' meaning "There is connection in link layer but there is no data exchange."
It was basically 'hung,' and 'ethercat -p0 states PREOP' failed to bring it out of OP state.

I repeated:
I powered up the slave afresh and ran the bash script to configure the PDOs, but this time I left it in PREOP when I started up lcec.
The slave stayed in PREOP mode.
The LINK light went to 'continuously on' again. It was basically 'hung' again and 'ethercat -p0 states OP'

I repeated with a twist:
I powered up the slave afresh and ran the bash script to configure the PDOs and again left it in PREOP before starting lcec.
This time, though, I changed configPdos="true" in the xml's 'slave' line to "false". I did this because, hey, the PDO's already got configured by the bash script, so why let the xml mess it up? (I also took out the sdoConfig stanza.)
Same thing: stayed in PREOP, LINK light stuck on.
No love!

Dead end #3:
"No error" from 'ethercat states' command, hmm? Perhaps, I thought, it's getting to OP just fine, but then getting chased out by ... a watchdog, maybe? I fiddled with my xml watchdog line, but nothing seemed to make a difference.

Dead end #4: do it the hard way
I built a custom lcec_pn4.c driver, but did not get better results. I found out the hard way that calls like ecrt_slave_config_sdo16() don't work in RT code. (Just like it says. Duh.)
I can believe that I screwed this up, so I won't drag you through it.
It seemed to me, though, that pretty much nothing in the xml was getting written to the slave, so I hacked the code with some rtpi_print_msg()'s so that I could watch as rtapi_app_main() and the generic driver processed the correct indices into the correct ecrt_whatever() calls, with good return codes. Everything looked good.
And yet, when the xml does something like: and then I terminate lcec and go back to the command line, shouldn't
ethercat -p0 -t uint8 upload 0x6098 0
return 23? It returns whatever was in it before lcec ran, as though the sdoConfig never happened.
It's almost as though there were some kind of write-protect against sdo updates while lcec is running.

In all these cases, all the right hal pins are created, but all the inputs from the slave were false or zero.

It wasn't long ago that this was all greek to me, but by now, most of the code, docs, xml, concepts and samples make perfect sense, and this really ought to be straightforward.

Clearly, I'm doing something stupid, but what?

Thanks,
Reid

Hello Reid,
a clue would be to look at the error report in the driver through the TWINCAT3 program to see what error it gives you, another thing is that you should load the whole servo configuration through the generic module before reaching your OP status, another thing is [450871.108535] EtherCAT ERROR 0-0: SDO cancellation message 0x06020000: "This object does not exist in the object directory". this parameter does not exist ??? another thing, does it work through TWINCAT3 ??? , otherwise the network cable is CAT5 or CAT6 ??, greetings Chimeno