[etherlab-users] Distributed Clock with Yaskawa SGDV drives

[George Broz]

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