[etherlab-users] RV: AX5000 fault synchronism

[Tom Wong-Cornall]

On Fri, Nov 01, 2019 at 11:37:55AM NZDT, Gavin Lambert <gavin.lambert at tomra.com> wrote:
>For example, I have a slave which wants SYNC0 at 250us intervals and SYNC1 at 
>1ms intervals, with no shift between them (but a slight shift on SYNC0).  The 
>correct values for this configuration are 250000, 5000, 750000, 0.

I can't quite square that up with the ET1100 docs, or the AX5000's behaviour 
in use.  Your description matches the high-level docs for the AX5000, which is 
to imply Sync0 will happen simultaneously with Sync1. However, the Beckhoff 
ESC docs describe the sequence occurring as my previous email, with Sync1 
occurring at "sync1 cycle time" (0x09a4) nanoseconds after Sync0 (see extract 
from PDF attached).

I also experimentally confirmed this with the AX5000, by using the common 
Sync0=250us, Sync1=750us and then progressively shifting Sync0 until the RPDO 
capture was aligned too closely with the telegram, causing synchronisation 
faults. This happens at either (roughly) S0 shift = +250us, or S0 shift = 
-750us, so I believe Sync0 cannot occur simultaneously with Sync1. This also 
explains why the default value of no (or little) Sync0 shift works quite well 
in practice.


Shifting S1 relative to S0 should work on the AX5000 if the only constraint 
was keeping S1 in phase with application cycle time. E.g. your example of 
s0=250us (+50), s1=800us:

    0us: Application reference time
   50us: S0 pulse, S1 timer started (800us remaining)
  300us: S0 pulse                   (550us remaining)
  550us: S0 pulse                   (300us remaining)
  800us: S0 pulse                   ( 50us remaining)
  850us:           S1 pulse
 1050us: S0 pulse, S1 timer started (800us remaining)
 1300us: S0 pulse                   (550us remaining)
 1550us: S0 pulse                   (300us remaining)
 1800us: S0 pulse                   ( 50us remaining)
 1850us:           S1 pulse

However the AX5000's firmware tries to do a "helpful" thing by throwing a 
fault code (I think F411) if S0 + S1 doesn't add up exactly to the application 
cycle time.

It could be that it's relying on S0 and S1 to stay at some fixed relationship 
to each other (the internal use of S0 is undocumented, only S1 is described as 
being used for RPDO latch). But my suspicion is it's just an out-of-band fault 
message (F411 from memory) for the purpose of telling people they're probably 
doing something daft.

The simplest way to check S1 will stay in phase relative to the application 
cycle time is doing a basic check that S0 + S1 = cycle, and for the AX5000 all 
the end user needs to do is adjust S0 shift. Given that the AX5000 is an old 
amplifier (circa 2004?) and very much a Beckhoff-internal meant-for-TwinCAT 
device (e.g it doesn't store any parameters internally, even motor type and 
commutation offsets are read from application at runtime, very "PC-based 
control"), that simple case probably covers all the firmware engineer thought 
they needed to.

Cheers,

Tom