On Fri, Nov 01, 2019 at 11:37:55AM NZDT, Gavin Lambert
<gavin.lamb...@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
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
