Jump to content
OMRON Forums

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


sutty
 Share

Recommended Posts

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)?

Link to comment
Share on other sites

  • Replies 36
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!!

Link to comment
Share on other sites

  • 2 weeks later...
  • 11 months later...
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...