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.
--- Begin Message ---Hi, I have attached a test app to have a look at. It is a (very) cut down version of how my app works. Of course I use RTAI, so it won't be compatible with your Xenomi environment. In main.c at the top of runECat() I have a list of EtherCAT devices and their addresses. It is hard coded here but can of course be loaded from a config file. The device names match devices in the etherCATSlaves.c file. etherCATMaster.c contains the code to configure and run the master. etherCATSlaves.c contains each slave's code. yaskawaSGDV_create() - configures the device and gets the PDO command offsets yaskawaSGDV_prepareToRun() - calculates each commands address (after the domains are populated and allocated) - sets cyclic synchronous position mode (optional, the mode can be set at any time while running) - sets the control word to zero, just in case yaskawaSGDV_run() - is called once each scan. add code here to control the axis yaskawaSGDV_prepareToStop() - is called when the app is closing. add any code here to clean up your axis Note: In this app the prepareToStop() functions are called once and then the app is shut down immediately. In reality you should continue your realtime cycle until all of the devices are stopped, disabled and safe to turn off. The app also relies on some of my patches. I hope this helps Regards, Graeme. -----Original Message----- From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Graeme Foot Sent: Wednesday, 16 August 2017 10:42 a.m. To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org Subject: Re: [etherlab-users] No CoE communication Hi, I've been asked to let you know what master version and patches I'm using. I'm still running an old version (2526 from the stable-1.5 branch, 12/02/2013). The script I use to download it is attached (004-etherlab_master). I use buildroot to create my linux system, so the script tar's the master folder and puts it in the buildroot downloads folder. Note: I also use a really old buildroot from 2012 with a few modifications, but I have attached the mk file that it uses. The patches that I apply are also attached. The build options I use are: --with-linux-dir="<linux dir>" --enable-cycles --enable-rtdm --enable-e100 --enable-e1000 --enable-e1000e --enable-cx2100 I use RTAI, but that shouldn't make any difference. Regards, Graeme. -----Original Message----- From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Graeme Foot Sent: Tuesday, 15 August 2017 12:39 p.m. To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org Subject: Re: [etherlab-users] No CoE communication Remember to reply-all to mail the forum as well. Line 85 has: #define Yaskawa_Sigma7 0x00000539, 0x02200301 This is different to my drive, so it may still be the Sigma 7 id causing a mismatch, but it is the id being returned from the ethercat struct command. Other than that, I've got no idea. Graeme. -----Original Message----- From: Rahul Deshpande [mailto:rahulg...@gmail.com] Sent: Tuesday, 15 August 2017 3:57 a.m. To: Graeme Foot <graeme.f...@touchcut.com> Subject: No CoE communication Hi Graeme, I understand I have been mailing a lot, my questions may seem repetitive. The positive now is I was able to get to OP state by forcefully setting 1c12 and 1c13 to 0 (PDO assignment fro SM2 and SM3). I am still not able to configure the PDOs though. What I have narrowed down to is, somehow CoE communication just does not happen. I was going through the etherlab forum and came across a post where they mentioned some sdo's had to be set prior to configuring the PDOs. Is it that ? Also, It would be great if I could just reach out to you on your phone if thats not an issue. Could sort out my problems faster and not disturb you with constant emails. Do let me know if thats an option. Thank you so much. Regards, Rahul<<attachment: yaskawaTest.zip>>
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
--- End Message ---
<<attachment: yaskawaTest.zip>>
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
