[etherlab-users] RV: AX5000 fault synchronism

[Tom Wong-Cornall]

On Fri, Nov 01, 2019 at 07:28:12AM NZDT, Albert Chimeno garcia <chime69 at msn.com> wrote:
>This configuration works:
>    <dcConf executeActivate = "730" sync0Cycle = "0" sync0Shift = "50000" sync1Cycle = "750000" sync1Shift = "0" />
>
>this is the old one
>   <dcConf executeActivate = "730" sync0Cycle = "250000" sync0Shift = "50000" sync1Cycle = "750000" sync1Shift = "250000" />
>
>So can syncxShift only be 0?

The AX5000 works a little differently to some other DC slaves. It takes its 
reference/PDO capture from Sync1, not Sync0 (as some other amplifiers do). The 
way this works is a little unintuitive, at least when reading the AX5000 
system manual. Some of this only becomes clear when reading Beckhoff's 
EtherCAT Slave Controller "Hardware Data Sheet" (see section 9.2.3.5 in 
"Section 1 - Technology", link here: 
https://download.beckhoff.com/download/document/io/ethercat-development-products/ethercat_esc_datasheet_sec1_technology_2i2.pdf


General principle:

 - You specify how often Sync0 is generated (happens internally inside drive).  
   There are fixed options for this. 250us is the slowest you can set it, but 
   perfectly fine for 1kHz. I have no idea how you're getting away with 
   Sync0=0, maybe in this case it defaults to 250us (I haven't read LinuxCNC's 
   source).

 - Sync1 cycle time is *not* actually a cycle time (as Beckhoff docs and 
   TwinCAT refer to it). It's actually a delay value for a timer. Sync1 timer 
   starts when the Sync0 pulse occurs. The timer won't restart while it's 
   still running (important!). A Sync1 "event" happens when the timer expires.

 - Sync0 + Sync1 timer values *must* add up to your cycle time (imposed and 
   checked by AX5000's internal logic).

 - You can shift the entire cycle forward and back relative to your 
   ecrt_master_application_time() call by changing the Sync0 shift value.


The result for Sync0 = 250us and Sync1 = 750us is the following:

   0us: Sync0 pulse, Sync1 timer started (750us remaining)
 250us: Sync0 pulse, Sync1 already running (500us remaining)
 500us: Sync0 pulse, Sync1 already running (250us remaining)
 750us: Sync0 pulse, Sync1 just finishing (0us remaining), Sync1 event
1000us: Sync0 pulse, Sync1 timer started (750us remaining)
1250us: Sync0 pulse, Sync1 already running (500us remaining)
1500us: Sync0 pulse, Sync1 already running (250us remaining)
1750us: Sync0 pulse, Sync1 just finishing (0us remaining), Sync1 event
2000us: Sync0 pulse, Sync1 timer started (750us remaining)


Adding a shift value for Sync0 at 50us produces this:

  50us: Sync0 pulse, Sync1 timer started (750us remaining)
 300us: Sync0 pulse, Sync1 already running (500us remaining)
 550us: Sync0 pulse, Sync1 already running (250us remaining)
 800us: Sync0 pulse, Sync1 just finishing (0us remaining), Sync1 event
1050us: Sync0 pulse, Sync1 timer started (750us remaining)
1300us: Sync0 pulse, Sync1 already running (500us remaining)
1550us: Sync0 pulse, Sync1 already running (250us remaining)
1800us: Sync0 pulse, Sync1 just finishing (0us remaining), Sync1 event
2050us: Sync0 pulse, Sync1 timer started (750us remaining)


>From this you can see two things. Firstly, Sync1 shift is totally unnecessary 
(you can get the shift you need to suit your cycle just from changing Sync0).  
Secondly, even Sync0 shift is really unnecessary if Sync0 is kept around a 
quarter of Sync1, as that puts the setpoint capture at three-quarters of the 
cycle after ec_master_application_time(), which is plenty of tolerance for 
getting your data sent and allowing for packet "wire time" (see Graeme Foot's 
extensive posts on DC sync methods on this list).

In the EtherLab version I use, when Sync1 shift is given, I see specifiying 
Sync1 shift simply adds the shift time to the delay value. This kind of makes 
sense as Sync1 "cycle" is really just the delay between a Sync0 pulse and 
Sync1 pulse (see ET1100 register 0x9a4:0x9a7). However this then falls afoul 
of the AX5000's requirement that Sync0 + Sync1 = application cycle time.


TLDR: The AX5000 is a little weird, you don't need Sync1 shift, it worked for 
you previously because Sync1 shift values were ignored by Etherlab, and the 
AX5000 was probably designed with the assumption Sync1 shift would always be 
0. Use Sync0 shift if you need it---but you probably don't.

Cheers,

Tom