[etherlab-users] Distributed Clock with Yaskawa SGDV drives
Henry Bausley
hbausley at deltatau.com
Tue Jan 31 17:00:36 CET 2012
Did you try changing the interpolation time period, index 0x60C2 sub
indexes 1 and 2 to match your cycle time?
On Tue, 2012-01-31 at 20:03 +1300, Graeme Foot wrote:
> 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-bounces at etherlab.org [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of George Broz
> Sent: Saturday, 28 January 2012 14:36
> To: Graeme Foot
> Cc: etherlab-users at 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-bounces at etherlab.org> wrote: -----
> To: <etherlab-users at 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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
Outbound scan for Spam or Virus by Barracuda at Delta Tau
More information about the Etherlab-users
mailing list