Hi Circle, Re the two emails below: ________________________________ > From: Circle Fang <circlef...@live.com> > Sent: Thursday, 17 April 2025 19:59 > To: Graeme Foot > Cc: etherlab-users@etherlab.org > Subject: 回复: DC synchronization demo about etherlab master > > Dear Graeme, > I am so sorry again, I am too excited to receive your email, and I can't wait > to know more. > One more thing, does ECAT Master set sync0 time for the slave? if so, what > type of frame for that(I want to check that by wireshark)? And is it aligned > with dc_start_time? As I understand app_start_time is the first call to > ecrt_master_application_time, some code says application_time should be phase > aligned with dc time, what does this mean? I am not clear about the purpose > of application_time if we don't sync all slaves to master clock. > > Wish you have a good time. > Best Regards, > Circle ________________________________ > From: Circle Fang <circlef...@live.com> > Sent: Thursday, 17 April 2025 19:47 > To: Graeme Foot > Cc: etherlab-users@etherlab.org > Subject: 回复: DC synchronization demo about etherlab master > > Dear Graeme, > if I call ecrt_slave_config_dc(NULL, 0x300, 1000000, 300000, 0, 0), does the > parameter 3000000 for sync0_shift only affect dc_start_time in the master, is > any other purpose? like, will will be copied to 0x1c32:3(shift_time), how is > it related to initial master_time and the first frame send time? > Also, when you mentioned " If you active the slaves dc, then the sync0 occurs > at the sync0_shift time after the nominal cycle zero time. ", what do you > mean by nominal? does sync0 event occurs first, then after shift time, slave > apply PDOs? and should we just care about is the time between frame arrival > and SYNC0(I mean shift time NOW is the internal things of slave, it should > not raise dc sync problems, just a shift time to apply PDOs)? > > Finally, i would like to share something, when my YASKAWA is synchronized > very well(servo_on, no dc error, drift of last slave is very small), the > 0x1c32:02=0x1c32:10=1000000, but 0x1c32:03=62500, > 0x1c33:02=0x1c33:10=1000000, 0x1c33:3=0(anyway i don't think we should care > 0x1c33 since we are not using SYNC1, right?). What's more, when I try another > 2 servos from HCFA(remove all YASKAWA servos), all the above values is > 0(cycle time and shift time in 0x1c32 and 0x1c33), but the servos are working > better than YASKAWA's. Have you any idea about this? > > > With KINDEST REGARDS > Circle
Re Yaskawa vs HCFA, if all the 0x1c32 / 0x1c33 values are zero then it is unlikely that the ecrt_slave_config_dc() call has succeeded. Check the ethercat logs for errors. If dc sync is not active on the HCFA axes then they will not raise sync errors. Instead they will most likely be in free run mode and just be applying the pdo values as soon as they receive them (which means they will not be coordinated). Also make sure the Assign Active value is correct for the HCFA axes. This value can be obtained from it's esi file (it may not be 0x0300). Re Yaskawa 0x1c32:03=62500. That doesn't look right and may be why you're having problems. 62500 is the smallest possible period the Yaskawa axes will accept. It also doesn't look like your shift time of 300us has been applied. So it's likely that these are the default values and dc sync has not been activated correctly at all. In your example you are passing NULL as the first parameter of ecrt_slave_config_dc(). This needs to be the slave config of the slave you want to activate DC sync on and needs to called for each slave that you want to activate DC sync on. Prior to calling ecrt_slave_config_dc() on any slave you need to have already started your realtime loop to ensure they don't raise DC sync errors due to missed PDO's. Re the rest, hopefully this answers everything: Your application is the master so you get to choose time zero and the cycle period. Just before activating the master you call ecrt_master_application_time(), passing it your time value you want to be considered time zero. In my example (previous email) I do this by taking the current clock time and rounding it down to the nearest even cycle period value (phase aligning it). It is then up to your application to cycle at your desired period. If you keep everything in sync then you will get something like: * Time Zero / Cycle Zero Time (time zero set with ecrt_master_application_time()) | cycle 0 (call ecrt_master_activate() and setup hard realtime) | wait for next cycle | * Cycle Zero Time (Time Zero + (Period * 1)) | cycle 1 (receive / calc / dc sync / send) | wait for next cycle | * Cycle Zero Time (Time Zero + (Period * 2)) | cycle 2 (receive / calc / dc sync / send) | wait for next cycle ... * Cycle Zero Time (Time Zero + (Period * n)) | cycle n (receive / calc / dc sync / send) | wait for next cycle | On the slave side you have three types of slaves: 1. Does not support DC at all 2. Has a DC clock (either 32bit or 64bit clock) 3. Has a DC clock and can be DC sync activated A slave must have a DC clock to be able to serve as a DC reference slave, but doesn't need to support DC sync activation. All slaves start up without DC sync activate by default. Slaves without DC sync activated get a sync0 signal when they receive the write PDO frame (and potentially a sync1 if they receive the read PDO frame in a separate domain). This means the PDO data is applied immediately on receiving it, so the first slave can apply it's outputs some time before the last slave does due to the physical time the frame takes to travel along the slaves. Slaves that allow the DC sync to be activated allow some arbitrary time offset (the sync0 shift time) from the Cycle Zero Time so that all of these slaves can trigger the sync0 signal at the same time so their outputs become coordinated regardless of where they are in the EtherCAT chain. Note: dc slaves do not need to have the same sync0 shift time applied to them but it would be unusual to do so. So, your sync0_shift time of 300000 is configuring the slave to have a sync0 signal occur 300us after Cycle Zero each cycle (where the cycle period is 1ms). What I mean by the nominal cycle zero time is: as the master you nominate Time Zero. Each cycle thereafter has a Cycle Zero time which is Time Zero + (Period * cycle number). Using ecrt_slave_config_dc() allows you to configure a slave to trigger the sync0 signal at a time of your choosing, in relation to the Cycle Zero time. This allows the slave to delay applying the PDO data, but the PDO data must have arrived before the sync0 signal is triggered else it has nothing to apply and it causes an error condition on the slave. Back on the master side, it is up to you when you wake up and perform the receive / calc / dc sync / send functions. It doesn't have to coincide with Cycle Zero, but each of the functions have various constraints. e.g.: * receive must be called after the frames have returned to the master from the previous cycle * dc sync (e.g. ecrt_master_application_time()) should be called just before send to minimize timing jitter * send needs to be called every cycle, after the previous cycles last active sync0_shift time and before the current cycles first active sync0_shift time (plus time allowance for time on the wire) So for a cycle you get something like: Master Slave 1 Slave 2 * Cycle n Zero time | wake up | receive | calc | dc sync | send ----------------\ | wait for next cycle \ | \- process pdo -\ | \- process pdo -\ | | | /---------------/ | /---------------/ | / | <--------------------/ | Sync0 Sync0 <= pdo data becomes active 300us after Cycle Zero | ... * Cycle n+1 Zero time | wake up etc... I'm not at work for the next week so can't look up the EtherCAT docs, but the DC related registers are in the 0x0900 range (with the assign activate at 0x0980, 0x0981). ecrt_master_application_time() is used to inform the master code what time we think it is. If we are syncing the master to the reference slave then we account for drift on the app side. I don't have the code in front of me so can't say at the moment whether it is necessary to be called each cycle in this situation (after the initial call to set Time Zero). Regards, Graeme. ________________________________ 发件人: Circle Fang <circlef...@live.com> 发送时间: 2025年4月17日 7:33 收件人: Graeme Foot <graeme.f...@touchcut.com> 抄送: etherlab-users@etherlab.org <etherlab-users@etherlab.org> 主题: 回复: DC synchronization demo about etherlab master Dear Graeme, Thanks so much for the detailed explanation. that really help me a lot. if I call ecrt_slave_config_dc(NULL, 0x300, 1000000, 300000, 0, 0), does the parameter 3000000 for sync0_shift only affect dc_start_time in the master, is any other purpose? like, will will be copied to 0x1c32:3(shift_time), how is it related to initial master_time and the first frame send time? ________________________________ 发件人: Graeme Foot <graeme.f...@touchcut.com> 发送时间: 2025年4月17日 0:26 收件人: Circle Fang <circlef...@live.com> 抄送: etherlab-users@etherlab.org <etherlab-users@etherlab.org> 主题: RE: DC synchronization demo about etherlab master Hi Circle, Re below, I’m also cc’ing the forum in case anyone has more input to add. > From: Circle Fang circlef...@live.com<mailto:circlef...@live.com> > Sent: Wednesday, 16 April 2025 20:02 > To: Graeme Foot graeme.f...@touchcut.com<mailto:graeme.f...@touchcut.com> > Subject: DC synchronization demo about etherlab master > > Dear Graeme, > > I am interested in some motion control research, and I am really thankful > about all your response in etherlab-users mail-list, that help me a lot. And > i am very sorry if my mail dirturbe you, I am not able to post questions on > the maillist. > > I like the way you mentioned here > https://lists.etherlab.org/pipermail/etherlab-users/2018-May/014740.html by > CACHED PDOs sent in next cycle, but i am not able to find the attachment you > mentioned here, > https://lists.etherlab.org/pipermail/etherlab-users/2022-March/019231.html. > Is it possible that you send me a copy? > > I am having dc sync error occasionally with 4 YASKAWA servos(first time with > this brand) connected a line to the master, even 0x92c is very small like no > more than 20. I am using xenomai in the traditional ways (the master is > synchronized to reference with PDOs in current cycle), and my realtime > cycle(1ms) takes various mount of time. And if my OS is ok, then the only > thing i can do is sync 0 shift_time(now 300us) and CACHED PDOs sent in next > cycle as you mentioned? Do you have any other suggestions? > > I also have one more question about sync0 and shift time, is "DC cyclic > operation start time to 64460955283935" the first sync0 time in slave? I saw > in some docs said the sync0_shift is only a time after snyc0 in the > slave(like all motors move at the same time, i.e., after shift time), If so, > why we use sync0_shift to calculate dc_start_time? because dc errors is about > the time SM2 and sync0, it's not because sync0_shift. > > This confuse me for several years, and I would be very very appreciated if > you give me some guidance. > > Thanks again > Circle I’ve attached the email you mention and the test program. Inside ecMaster_syncDistClock() I call ecrt_master_64bit_reference_clock_time_queue(). This is used to put a long running timestamp in the wireshark logs so you can check and ensure your cycle period is not drifting. If drifting is not the problem then calling ecrt_master_send() at a consistent time (with enough time on the wire before the DC Sync time at the slave) is essential. As you say, I do this by caching the data to write from the previous cycle and send it as soon as I receive and process the previous domain information. This ensures the previous frames have returned and reduces the jitter of the send. I also set the dc shift time on the slaves to 500us (half of my 1ms period) so that the frames have half the cycle to reach all the slaves and the other half of the cycle to return. (We only have 60 to 80 slaves so are nowhere near needing to worry about time on the wire, unless we decide at some stage to reduce the cycle period.) The calculations for the next period can then also be performed in parallel to the frames being on the wire. A few other options are: 1. Set your DC Sync offset to 900us. A time large enough to process the previous frame reads, do calcs, send and time on the wire. The drawback is that non DC slaves will apply their data more early than the dc slaves. 1. Wake up the master twice. E.g.: At 0us: Wake up and perform the send At 500us: Wake up and receive, do calcs At 1000us: Wake up and perform the send Etc. Also, people have asked the forum previously if you can wake up at an event when the PDO data frames return. There is no such event, so they have attempted to poll for this. The master is not designed for this so it doesn’t work so well. What you can do however is figure out how much time the frames take on the wire by looking at the “ethercat sl -v -p0” command and look at the Diff [ns] value for port 1 (or calc the diff between the first and last port if using a start topology). That will tell you how long it takes for the frames to go out and return to the first slave. Add a little overhead for the master send / receive and you can tune the mid cycle wake up time above to maximize the calc time. That of course then becomes system specific (and can change if you have hot plug groups). 1. Do what TwinCAT does and separate the calc from the EtherCAT processing (different threads and memory space). The EtherCAT module wakes up at 0us and reads linked data from other modules, it then reads the returned PDO information and caches it for other process to read, applies the PDO write data and sends it. The calc modules can wake up when they want and follow the same steps, read linked data from other modules (including the EtherCAT PDO data), perform calcs, write results to the modules out data. This is kind of similar to my caching method except that it uses the different modules to achieve the data caching and decouples the EtherCAT data cycle and calculations. It’s also helpful due to TwinCAT using overlapped PDO’s. Different calc modules can also have different cycle rates, but the EtherCAT module needs to run at least at the fastest module cycle rate. There’s also more locking issues to resolve and memory shuffling. Re your last question, I’m not really sure what you are asking but from my recollection: * The sync0 time is to do with getting all dc clock slaves to a common time base and in sync with your masters nominal cycle zero time. The dc syncing after that is just to keep the master and dc slaves in sync with each other. * By default slaves will apply data from incoming PDO’s immediately, and write outgoing data at their current values. DC capable slaves can optionally have DC sync enabled (with ecrt_slave_config_dc()), which effectively caches the incoming PDO data to be applied at the shift time, so all DC slaves can activate their incoming data at the same time (or in a coordinated fashion). It also caches write data at the same time (or at its own offset with sync1). The only requirement is that the slave needs to have processed the PDO frames each cycle before the offset time, else it starts raising errors. * The master can choose when in the nominal cycle period it sends the PDO frames, but as close to the cycle zero point with minimal jitter is preferable. (Minimal jitter is especially good for the non dc activated slaves.) ecrt_slave_config_dc() params: sc the slave to configure assign_activate the assign activate word the slave uses to enable DC sync (often 0x0300) (see ETG ethercat_esc_datasheet_sec2_registers pdf, registers 0x0980, 0x0981) sync0_cycle your nominal EtherCAT master cycle time (e.g. 1ms) sync0_shift when to raise the sync0 event, as a shift time from the nominal cycle zero time (aka when to apply the read PDO values in the cycle period) sync1_cycle some slaves can have a sync1 event, used for caching PDO write values at a different time to sync0. Not generally required, use 0 to ignore sync1_shift not generally required, use 0 to ignore. The master has a bug with this. There’s a patch floating around to fix this if needed In summary, the sync0 event is when the PDO data is applied. If you active the slaves dc, then the sync0 occurs at the sync0_shift time after the nominal cycle zero time. If it is not activated the sync0 event is raised as the PDO data comes in so it is applied immediately. Regards, Graeme.
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
