Hi, Yes I have thanks. My cycle time is 1ms. I have set: 0x60C2, 0x01 = 1 0x60C2, 0x02 = -3
Graeme. -----Original Message----- From: Henry Bausley [mailto:hbaus...@deltatau.com] Sent: Wednesday, 1 February 2012 05:01 To: Graeme Foot Cc: etherlab-users@etherlab.org Subject: Re: [etherlab-users] Distributed Clock with Yaskawa SGDV drives 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-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 Outbound scan for Spam or Virus by Barracuda at Delta Tau _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users