Tuning ECAT-drive in CSV-mode - howto set filter gains via SDO, ecattypedsdo() fails

[sutty]

Hi Alex!

I've changed Phase/Servo/RTI from 32/16/4 to 8/2/2 kHz - now ecattypedsdo() reads values:

l0=ecattypedsdo(0,1,1,$1000,$0,0,4) l0

L0=131474

l0=ecattypedsdo(0,1,1,$2002,$14,0,4) l0

L0=150

l0=ecattypedsdo(0,1,1,$2002,$15,0,4) l0

L0=37

 

 

But in the motor topology still the drive EL7211-0011 does not show up!!

 

Will you provide a bugfix for ecattypedsdo() in case of high phase-frequencies (32kHz)?

[Alex Anikstein]

To clear up a few misconceptions:

 

-EtherCAT is based off of the Servo Clock, not the Phase Clock

-As EtherCAT is based off of increments of 62.5uS, it is not expected to work at faster than 16kHz (and even that speed exceeds the limitations of most devices)--I am not sure if this is a limitation of our implementation or if this is a normal EtherCAT spec, but I haven't seen EtherCAT conforming devices rated for faster than 16kHz, and more commonly 8kHz is the fastest I've seen for drives

-I am not sure what speed you are using EtherCAT, but I suspect that you are not properly setting ECAT.ServoExtension to accomodate having different values for your servo clock and your EtherCAT clock.

 

Can you please query:

l0=ecattypedsdo(0,1,1,$492,0,0,4) l0

 

$492 may not be 32-bit (size = 4), so if that gives nan, please query other sizes. In general, any device that is properly identifying itself as a drive will show up as an option in the system setup. If it's not there, it's either because we can't read the settings from the drive by using ecattypedsdo or that the devices are not properly identifying themselves in registers $1000 (which you queried) and $492.

[sutty]

Sorry, in my case the ecattypedsdo() function seems not being stable.

I can't get any value from any of those addresses anymore. Also not on lower servo-frequencies.

I will try it next week again.

 

Is their any advice for savely using this function?!

 

By the way, of course, ServoExtension was well set since all the time to meet the 1ms cycle time of ECAT.

[JeffB]

In my limited experience, if you type something wrong with ecattypedsdo it will return nan and continue to return nan even on correct parameters until reset.

[sutty]

Thanks, Jeff!

Do you mean ecatreset or $$$ or $$$***!?

[sutty]

Hi Jeff!

Now I found the reason for the mailfunction of ecattypedsto() --> ECAT[].ServoExtension

If set to match the ECAT Cycle time (eg 1ms Cycle time, Servo-Freq 16 kHz --> ServoExtension=15) then the function ecattypedsdo() delivers "nan" all the time.

If ServoExtension=3 or less, then the function ecattypedsdo() works correctly and delivers reasonable values all the time.

The lower ServoExtension, the higher its reliability.

Thanks anyway for your efforts!

[JeffB]

Glad its working for you. I have the ecattypedsdo called thousands of times a day on our robot as a check for errors before it does a task. Once and a while, when I'm debugging something else ecat related in the terminal, it will start to receive NaNs. Then I usually do $$$ first, then $$$*** if necessary.

 

I wonder if the ecatypedsdo reading has to occur between the PDO transfers, so if you're transferring more PDO variables or have shorter update periods due to ECAT[].ServoExtension, you have less time for ecatypedsdo. My mental model of the EtherCAT communication still has a lot of holes.

[Alex Anikstein]

That behavior still sounds odd to me such that I'm going to try to look into it in the coming weeks, though admittedly, it's a bit hard to do so as I didn't think to bring any ECAT slaves while working remotely.

 

As for SDO reads during EtherCAT communication, that's close, Jeff. We typically don't recommend issuing too many SDO commands while EtherCAT is enabled specifically because, depending on the exact timing of it, it can cause interference and problems. I believe it is more related to if an SDO read forces the PDO read to take too long that it rolls over into the next PDO read period. This isn't too likely to happen if you just are reading one SDO every few EtherCAT cycles, but if you start reading too many of them or too frequently, this can break things a bit. Because of this, if someone is reading SDOs very often, we strongly recommend they investigate mapping them as PDOs altogether or possibly lowering their EtherCAT rate.

 

However, this would be somewhat contradictory to the "fix" sutty found (where a slower EtherCAT rate causes intermittent issues), hence wanting to look into that more.

[sutty]

Hi Alex!

Take in account that in my case ECAT runs in busshift-mode! Besides everything else is on default-setting.

I need SDOs only for tuning-issues (setting gains) - so as a workaround I can change ServoExtension for that goal, and set it back after each SDO-write-access.

Anyhow, thanks for keeping track on this!!

[sutty]

Hi Alex!

Did you get to do some testings meanwhile?

Any news?

[hjpark]

Hello,

I am having the same problem.

Any updates?

[bill.lackey]

Same issue.  If you set servo extension to 3 it will fail.  Setting it to 0 works pretty much all the time.