Hi, I have been playing with various options but I'm still getting a drift on my slave relative to the master.
What I have found so far: 1) It looks like my slave requires no other frames on the ring when first setting up the distributed clocks (thanks for pointing that out George). - I now run only the distributed clock functions for 1 second before adding in the polling pdos. - This seems to make the System Time Diff (0x092C:0x092F) value remain small, but the Speed Counter Diff (0x0932:0x0933) remains at zero. 2) The System Time Delay (0x0928:0x092B) is a negative number. The reported slave delays are: Slave 0 (CX1100-0004) 0 ns Slave 1 (EK1110) 140 ns Slave 2 (EK1100) 2670 ns Slave 3 (EL2602) 2815 ns Slave 4 (EL2008) 2960 ns Slave 5 (EL1008) 3100 ns Slave 6 (EL1018) 3240 ns Slave 7 (EL3162) 3385 ns Slave 8 (EL4132) 3530 ns Slave 9 (Yaskawa SGDV) 2147486168 ns (-2520) Slave 10 (Yaskawa SGDV) 2147487253 ns (-3605) The last two being the ones with the problems. I still need to look into how the calculations are working with 32 bit dc. 3) The System Time Diff (0x092C:0x092F) is jumping around small -ve and positive numbers but the Speed Counter Diff (0x0932:0x0933) is remaining at zero. If there was drift in the local clock I would have expected the System Time Diff to get bigger or the Speed Counter Diff to become non-zero to compensate for the drift. Some example values: Recieve Time Port 0 (0x0900:0x0903): 0x6c18cae8 1813564136 Recieve Time Port 1 (0x0904:0x0907): 0x6c18d362 1813566306 Recieve EPU (0x0918:0x091F): 0x000000006c18cae8 1813564136 System Time (0x0910:0x0917): 0x00000000e7ce6469 3889063017 System Time Offset (0x0920:0x0927): 0x0000000048df3bfd 1222589437 System Time Delay (0x0928:0x092B): 0x800009d8 -2520 System Time Diff (0x092C:0x092F): 0x00000003 3 Speed Counter Start (0x0930:0x0931): 0x1001 4097 Speed Counter Diff (0x0932:0x0933): 0x0000 0 4) In the examples there are two methods used to pass the time to ecrt_ master_application_time: a) in the kernel space example it is just adding the scan time to the current time, eg: dcTime += 1000000; ecrt_master_application_time(master, dcTime); b) in the user space example it gets the time every cycle, eg: clock_gettime(CLOCK_TO_USE, &time); ecrt_master_application_time(master, TIMESPEC2NS(time)); I'm using RTAI LXRT with rtdm. I have confirmed that my cycle times are consistent and when using rt_get_cpu_time_ns (with method b) I am not getting drift at the master. I've also tried method a with no different result. I still need to match the slave time against the master time, but I'll need to read the register (via rtdm) to do that 5) I'm calling ecrt_slave_config_dc on the SGDV drives after the system is up and running but the sync Cyclic Unit Control and Activation (0x0980:0x0981) bytes remain zero as does the SYNC 0 Cycle Time (0x09A0:0x09A3). eg: ecrt_slave_config_dc(slave->sc, 0x0300, g_app.scanTimeNS, 500000, 0, 0); Results in: SYNC 0 Start Time (0x0990:0x0997): 0x0000000048df3ad1 1222589137 SYNC 0 Pulse Length (0x0982:0x0983): 0x03e8 1000 SYNC 0 Cycle Time (0x09A0:0x09A3): 0x00000000 0 Sync activation (0x0980:0x0981): 0x0000 0 I still need to look at the code as to why this might be happening. If I fill in these values manually, the start time starts ticking away as it should, but I still get drift. (ie setting SYNC 0 Cycle Time (0x09A0:0x09A3) to 1000000; Sync activation (0x0980:0x0981) to 0x0300) Apart from a couple of things mentioned above that I still need to look into, does anyone have anything else I should consider? Also a couple of questions: - The first slave with a distributed clock becomes the reference slave. Is there any way to find out which slave that is? (I haven't looked into the code yet.) - Does the slave that is being used as the reference clock need to have its distributed clock enabled (with ecrt_slave_config_dc)? I am using the latest 1.5.0 stable master: # ethercat version IgH EtherCAT master 1.5.0 ec8e1151b8a7+ Regards, Graeme. -----Original Message----- From: etherlab-users-boun...@etherlab.org [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of George Broz Sent: Saturday, 28 January 2012 14:36 To: Graeme Foot Cc: etherlab-users@etherlab.org Subject: Re: [etherlab-users] Distributed Clock with Yaskawa SGDV drives Hi, It looks like the propagation (transmission) delay determination is failing. That algorithm runs on driver insertion, if there is a bus change, or if you use the command line tool and issue 'ethercat rescan'. You can see the result (its register is 0x0x928) using: ethercat -p $1 -t uint32 reg_read 2344 4 (where $1 is your slave position.) The number returned is in nanoseconds. It should return with something that's a couple of hundred or a few thousand nanoseconds. This is then used with the the System offset register (0x920) to produce a System time from the slave's local time. For starters, I'd try to write directly to the 0x928 register supplying something reasonable. For example: ethercat -p $1 -t uint32 reg_write 2344 1300 That value will stay in there as long as your bus configuration does not change or is not scanned. That's just to make sure the slave takes a value. If that works, you can take a quick look at the receive times for each port. These will change whenever the propagation delay algorithm is run (e.g. ethercat rescan). These are what make the propagation measurement possible. Only pay attention to the ones where you have a physically connected slave (unconnected ports return a number - something that looks uninitialized, perhaps down at the slave?). echo "Receive Time Port 0 - 0x0900:0x0903:" `ethercat -p $1 -t uint32 reg_read 2304 4` echo "Receive Time Port 1 - 0x0904:0x0907:" `ethercat -p $1 -t uint32 reg_read 2308 4` echo "Receive Time Port 2 - 0x0908:0x090B:" `ethercat -p $1 -t uint32 reg_read 2312 4` echo "Receive Time Port 4 - 0x090C:0x090F:" `ethercat -p $1 -t uint32 reg_read 2316 4` (where $1 is the slave position). The difference between the numbers returned for connected ports should be small (thousands of nanoseconds). There is a note in the EtherCAT spec that states that for some slaves the ring has to be empty of all other frames before the broadcast write packet associated with this measurment can work (see Beckhoff EtherCAT ET1100 datasheet section 9.1.2, just above table 26.) That would require support from the master. Perhaps your Yaskawa drives fall into that category. I have no experience with 32 bit DC slaves. Maybe there is a bug there? BTW - if you want to view 0x92c (or others like it) with sign bit removed use - ethercat -p $1 -t sm32 reg_read 2348 4 Best regards, --George Broz Moog, Inc. Industrial Group -----<etherlab-users-boun...@etherlab.org> wrote: ----- To: <etherlab-users@etherlab.org> From: Graeme Foot Sent by: Date: 01/26/2012 06:38PM Subject: [etherlab-users] Distributed Clock with Yaskawa SGDV drives Hi, I'm having a problem with my Yaskawa SGCV drives. I am using them with Cyclic Synchronous Position Mode. The problems is that while moving they frequently get an unstable position error. The unstable position errors last for about ΒΌ of a second and occur regularly every 4 (approx) seconds. The position error is always less than the cycle delta position. I am setting up the drives to use the distributed clock but I am suspecting that something is not set up correctly and the position error is occurring due to a drift in cycle relative to the master. The "DC system time transmission delay" (from the "ethercat slaves -v" command) for the drives are: drive 1 (slave 9): 2147486148 ns drive 2 (slave 10): 2147487218 ns They are being reported as 32bit distributed clocks. When doing the "ethercat reg_read -p<slave> -tint32 0x092C" command on each of the slaves then the slaves prior to the yaskawa drives get numbers such as: 0x00000010 16 0x00000024 36 0x80000011 -2147483631 0x80000004 -2147483644 Where the low order bytes contain low numbers but the sign bit may be on or off. However, the yaskawa slaves are more like: 0x66a32ed9 1721970393 0x669f8483 1721730179 0x669d0223 1721565731 0x669b553f 1721455935 If I disconnect the drives then the rest of the slaves still behave the same (where the sign bit may be on or off). Does anyone have any ideas what I should be looking at next? Regards, Graeme Foot _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users