[etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

[Graeme Foot]

Hi,

Ok, ignore what I said earlier.  I was misdiagnosing the problem.


This is what was going on (sorry if it's a bit long):


I'm using RTAI but I was not calibrating my cpu-frequency.  By default Linux only calibrates the cpu-freq to the PIT timer to an accuracy of 500 parts per million.  So each time I rebooted I could get quite varied cpu-freq values.

When they were outside a good operating range I would often get:
  EtherCAT WARNING 0-9: Slave did not sync after 5001 ms.

And sometimes get:
  EtherCAT DEBUG 0-9: OP -> SAFEOP + ERROR.
  EtherCAT ERROR 0-9: AL status message 0x001A: "Synchronization error".

The drive would then report an error code of 0x0A12 (sync error).

When I changed my code to start cycling the pdo information and the dc information before calling ecrt_master_activate() the problem pretty much went away.  But I would often still get the odd sync error at some later stage.


Now after calibrating my cpu-freq value, doing a lot of other stuff and generally gathering more knowledge I see the original diagnosis was wrong.  All that was happening was that the drives could not stay synced if the masters time cycle was too fast or too slow.  Starting to cycle the dc information sooner seemed to help them stabilise better on startup but they would still sometimes loose sync at a later stage anyway.

(Note: I'm setting my calibrated cpu-freq by using the "rtai_cpufreq_arg" when calling insmod on rtai_hal.ko.)



However, I also had a problem when deactivating the master.  When calling ecrt_master_deactivate() the pdo data can no longer be sent (as the pdo memory is destroyed).

This would lead to the following errors:
  EtherCAT ERROR 0-7: AL status message 0x001B: "Sync manager watchdog".
  EtherCAT 0-7: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-8: AL status message 0x001B: "Sync manager watchdog".
  EtherCAT 0-8: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-9: AL status message 0x001A: "Synchronization error".
  EtherCAT 0-9: Acknowledged state SAFEOP.
  EtherCAT ERROR 0-10: AL status message 0x001A: "Synchronization error".
  EtherCAT 0-10: Acknowledged state SAFEOP.

(Slaves 0-7 and 0-8 are an analog input and output, slaves 0-9 and 0-10 are the Yaskawa drives.)

This is due to slaves still being in OP mode for a little bit after the deactivate call.  To solve this I have added a new function called ecrt_master_deactivate_slaves() (and ecrt_rtdm_master_deactivate_slaves()).

This lets me deactivate the slaves while still sending pdo information.  I wait until all the slaves are in PREOP mode (masterState.al_states == 0x02) before I stop my hard realtime cycle and call ecrt_master_deactivate().



And last of all there is another problem that I encountered which also helped throw me off:

If I use my Beckhoff CX1100-0004 coupler (32bit distributed clock, built into the CX1020 PC) as the dc reference slave, the Yaskawa SGDV System Time Diff (0x092C:0x092F) is only semi stable and dances around 600 - 800 ns (approx).

When I use the Beckhoff EK1100 coupler (64bit dc) or one of the Yaskawa SGDV amps (32bit dc) as the reference slave, the Yaskawa SGDV System Time Diff (0x092C:0x092F) is nice and stable at around +-20 ns.

The Yaskawa SGDV also does not provide the Speed Counter Diff (0x0932:0x0933) register.


Does anyone else use the Beckhoff CX1100-0004 coupler and have seen similar problems?



As part of all this I've made a little patch for the DC clock code, some of which you may be interested in.  I'll put this in a separate email.


Regards,
Graeme.



-----Original Message-----
From: Graeme Foot 
Sent: Tuesday, 13 March 2012 10:52
To: 'Florian Pose'
Cc: etherlab-users at etherlab.org
Subject: RE: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

Hi,

Right, I see what you mean.

I hadn't sorted out my timing issues back then so it is more like due to that.  I've almost finished what I'm currently working on so I'll revisit it and get back to you.  


Graeme.



-----Original Message-----
From: Florian Pose [mailto:fp at igh-essen.com] 
Sent: Monday, 12 March 2012 22:08
To: Graeme Foot
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 12.03.2012 00:03, schrieb Graeme Foot:
> Hi,
> 
> The slaves are not in OP before ecrt_master_activate().  They are
> in OP after ecrt_master_activate(), but before the first PDO
> datagrams were sent.

But this is what the application is responsible for. After activating
the master, the ecrt_master_send()/receive() methods have to be called
by the application, otherwise *no* bus communication (including slave
configuration) will take place. That's why I'm not understanding, why
slaves can go to OP before 'seeing' the fist process data...

> I was sorting out a few problems I was having at the time, so it's 
> probably not such an issue anymore.  However the main issue is that
> I'm running from a user space thread in RTAI.
> 
> What I originally had was:
> 
> ecrt_master_activate() ... setting up app objects to use pdo data
> etc ... rt_make_hard_real_time() rt_task_make_periodic(...,
> firstScanTime, ...) rt_task_wait_period() while (true) { ...
> ethercat polling stuff etc ... rt_task_wait_period() }
> 
> I needed to call ecrt_master_activate() (and then set up objects 
> referring to the pdo data) before making the thread hard realtime.
> In the time it took for the first hard period to start some of the
> slaves had already reached OP mode and missed a couple of PDO
> datagrams.

See above, after ecrt_master_activate() is called, there is no bus
configuration until you call ecrt_master_send() cyclically.

> So instead of that, I added an ethercat function to allow
> pre-assigning of the pdo data from user space so that the pdo data
> objects could be set up before calling ecrt_master_activate().  I'm
> also putting the ecrt_master_activate() call in a non-hard realtime
> helper thread so there is minimal time between the
> ecrt_master_activate() call and the PDO packets starting to be
> sent.
> 
> It all comes down to ecrt_master_activate() not being able to be
> called from a hard realtime thread in RTAI because it drops the
> thread out of hard realtime.

Sure, because memory has to be allocated. It never was never meant to
be called in real-time.

So before futher discussions I would like to have an explanation, why
the slaves are configured before the application calls ecrt_master_send().

Could you tell me the exact code revision including all patches you use?

- -- 
Viele Grüße,
Florian
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9dvNMACgkQABFOIMygR8w43gCfTxQNvONoIgTnwWubf55ih3rA
ekoAnA9IRkZwPkzq+KPxwijhAld5+4Lc
=aGCa
-----END PGP SIGNATURE-----