Hi Celil, Gavin mentioned seeing a user space example program at some stage. I don't know if this is the one he was thinking of, but I have previously posted a cut down version of my app (email attached) to show how I control Yaskawa axes. This application syncs the master PC to the slave reference clock.
Regards, Graeme. From: Etherlab-users <etherlab-users-boun...@etherlab.org> On Behalf Of Gavin Lambert Sent: Tuesday, 1 March 2022 12:01 To: Celil Can Anık <bilko.ce...@outlook.com>; etherlab-users@etherlab.org Subject: Re: [Etherlab-users] Using DC to syncronise to reference slave clock The only difference between ARMW and FRMW is the addressing mode for the slave; there is absolutely no reason this would cause synchronization issues, provided that both select the same slave as reference clock. (The only "advantage" of ARMW over FRMW is that you can be a bit lazier with the former if declaring that your first slave is always your reference clock - and indeed you do want your reference clock to be earlier in the network than any slaves where you care about their times.) There's fundamentally two different ways to try to sync the master clock and slave reference clocks. The first is to use the ecrt_master_sync_reference_clock or ecrt_master_sync_reference_clock_to calls, which will try to keep the clocks fully aligned, essentially by trying to make the slave clocks drift approximately the same as the master's. The second is to instead only call ecrt_master_reference_clock_time or ecrt_master_64bit_reference_clock_time (the latter requires extra steps) to only read the reference clock's existing time and then perform your own (usually virtual) adjustment to the master clock as needed. Most of the examples only demonstrate the former; the rtai_rtdm_dc example is the only one that demonstrates the latter. Which way makes more sense depends on which clock you expect to be "better", as well as whether you need the slaves to have something close to the "real" wall-clock time (only matters for 64-bit DC slaves) or if a relative close-to-zero clock is sufficient for their needs (usually true). Separate to this is the timing loop for your master packets. When using the former method you typically just try to send at a steady timestamp based solely on the master clock. When using the latter, you can still do that if you don't mind jitter and drift, but it's better to try to realign your master cycle based on the reference clock (the rtai_rtdm_dc example demonstrates this as well - be careful you didn't accidentally eliminate that when converting to userspace calls; system2count is critical here). It's also critically important to consider which values you're using in the ecrt_slave_config_dc call - make sure they match your vendor's recommendations for your intended cycle interval. In particular, selecting a good shift value may reduce the effect of jitter, where reasonably tight. (Also bear in mind that sync0 and sync1 cycle/shift times are not treated equivalently.) Bear in mind that you usually want your packets arriving at a different time from the Sync0 trigger on the slave, allowing for capture and processing delays plus jitter. It may be useful to connect a scope to observe the relative timing of each event. I vaguely recall there being a userspace variant of the example code posted to the list a few years back, but I didn't manage to find it in a basic search. Gavin Lambert Senior Software Developer TOMRA Fresh Food [cid:image001.png@01D82D6D.05B8C530] [tomra facebook] <https://www.facebook.com/TOMRAFreshFood> [tomra linkedin] <https://www.linkedin.com/company/tomra-fresh-food/> [tomra vimeo] <https://vimeo.com/tomrafreshfood> [tomra instragram] <https://www.instagram.com/tomrafood/> Compac Technologies Ltd | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand Phone: +64 96 34 00 88 | https://www.compacsort.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. From: Celil Can Anik Sent: Tuesday, 1 March 2022 03:11 To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> Subject: Re: [Etherlab-users] Using DC to syncronise to reference slave clock Hi again, I still work on running Mitsubishi JET servo drives. We managed to run with DC synchronized to slave reference clock. When we check Wireshark data, "System Time Register" 0x910 is transferred with FRMW command. But engineers from Mitsubishi had told us Beckhoff Ethercat master is using ARMW command for "System Time Register" 0x910. Honestly, I don't have any idea why, but they claim this command difference causes synchronization problem. What do you think about this topic? Also, I checked the source, but couldn't found usage of ARMW command. Is there any example for ARMW command? Best regards, Celil Hi, How should we use DC to synchronize to the slave reference clock? I implemented it by looking at the rtai_rtdm example. But it's not working as desired. I guess I'm missing something. I would expect to change my sleep times to synchronize to slave clock. I couldn't see something like that. * How can I stop drifting my send time relative to slave clock? * Also, how can I measure the time I'm sending relative to cycle start of the slave clock? Can I just modulo the value returned by ecrt_master_reference_clock_time() to the cycle time? For a little background: We are using EtherCAT master for several years. We are using PREEMPT_RT patch with ubuntu 16.04, kernel 4.9.178. We had downloaded Gavin Lambert's unofficial patch sets a few years ago. Normally we are using master PC as the master clock. This option is mentioned as option a in various mails in the mail list. With this method we successfully integrated many servo motor drives from several vendors. We are generally using 1ms and 2ms cycle times on different machines. We have recently added Mitsubishi Jet EtherCAT series to our database. Although this drive is working fine under lab conditions, somehow it gave synchronization errors from time to time at the machine. There are 4 drives and several IOs from Beckhoff on the bus. Mitsubishi engineers claim that, the problem occurs because we are not synchronized to the slave reference clock. And ask us to change our mechanism to synchronize the master PC to the reference slave. This method is also described as the option b in mail list. So I copied the related blocks from rtai_rtdm example in the examples folder. I modified RTAI specific functions to user space functions. At our lab we are testing two Jet drives connected to our master PC. The drives are changing to OP mode and I can control the position and speed. There is no error in dmesg messages. Also no error on the display of the drives. But I hear knocking sounds in every few minutes while rotating. It seems my send time is drifting relative to slave clock. But I don't see how can I stop drifting. Best regards, Celil
--- 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 ---
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
