EtherCAT slaves only internally have three sync timing registers: 1. Sync0 cycle time 2. Sync0 shift time 3. Sync1 "cycle time" (but it's actually a shift time that can have the appearance of a cycle time depending on its value).
In the stable branch of Etherlab, the parameters you specify are directly passed to the slave's registers without any modification or interpretation. This means that the sync1_shift value is completely ignored, because there is no register for it to be sent to. Instead, as documented in the slave register guide, the sync1_cycle can act as a cycle or a shift (or both) depending on its value relative to the sync0_cycle. In the unofficial patchset, due to patch base/0032-dc-sync1-offset.patch (might be named differently in older versions), ecrt_slave_config_dc has the same behaviour as before only when sync1_shift is 0. Otherwise, it performs a calculation between sync0_cycle, sync1_cycle, and sync1_shift to determine the value actually sent to the slave's "sync1 cycle time" register. (Technically, it always does the calculation, but the result is the same as before when sync1_shift is 0.) For example, I have a slave which wants SYNC0 at 250us intervals and SYNC1 at 1ms intervals, with no shift between them (but a slight shift on SYNC0). The correct values for this configuration are 250000, 5000, 750000, 0. If I wanted to have 50us delay between the SYNC0 and SYNC1 pulses, this could either be written as 250000, 5000, 800000, 0 (old style) or 250000, 5000, 750000, 50000 (new style). As you can see, the shift value is a little more obvious using the new format. But also note that in both formats the 1ms interval appears nowhere -- it is derived from both the SYNC0 and SYNC1 cycle times. You can't set the sync0 cycle to 0 though -- that just disables both DC syncs entirely. Gavin Lambert Senior Software Developer COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand Switchboard: +49 2630 96520 | https://www.tomra.com The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication. -----Original Message----- From: Tom Wong-Cornall Sent: Friday, 1 November 2019 10:33 To: Albert Chimeno garcia <chim...@msn.com> Cc: etherlab-users@etherlab.org Subject: Re: [etherlab-users] RV: AX5000 fault synchronism On Fri, Nov 01, 2019 at 07:28:12AM NZDT, Albert Chimeno garcia <chim...@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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload.beckhoff.com%2Fdownload%2Fdocument%2Fio%2Fethercat-development-products%2Fethercat_esc_datasheet_sec1_technology_2i2.pdf&data=02%7C01%7Cgavin.lambert%40tomra.com%7C07d89cc0838e4a9a509c08d75e49e2b7%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637081543752927305&sdata=%2B76bHZUsi%2FL74JYZ%2FIvLoqZqJxGVsGmQGqZ%2BU43ObMg%3D&reserved=0 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 _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7Cgavin.lambert%40tomra.com%7C07d89cc0838e4a9a509c08d75e49e2b7%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637081543752927305&sdata=aUKMrYw0eItNnd1OkRp5FWNBMDJTu%2BbP4uiWdEbZg7M%3D&reserved=0 _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
