I'm not talking about the AX4000. I'm talking about a different slave which does work happily with SYNC0 and SYNC1 occurring simultaneously. (Though it too is expecting one SYNC1 pulse per SM packet.)
With the specific parameters 250000, 5000, 750000, 0; what (conceptually) happens is this: 1. time 5000 : SYNC0 #1 (we assume the zero time is the DC start base for the network; YMMV) 2. time 255000 : SYNC0 #2 3. time 505000 : SYNC0 #3 4. time 755000 : SYNC0 #4 and SYNC1 #1 5. time 1005000 : SYNC0 #5 6. time 1255000 : SYNC0 #6 7. time 1505000 : SYNC0 #7 8. time 1755000 : SYNC0 #8 and SYNC1 #2 ... With the parameters 250000, 5000, 750000, 50000; the result would be more like: 1. time 5000 : SYNC0 #1 2. time 255000 : SYNC0 #2 3. time 505000 : SYNC0 #3 4. time 755000 : SYNC0 #4 5. time 805000 : SYNC1 #1 6. time 1005000 : SYNC0 #5 7. time 1255000 : SYNC0 #6 8. time 1505000 : SYNC0 #7 9. time 1755000 : SYNC0 #8 10. time 1805000 : SYNC1 #2 ... Negative shifts are also possible, for example 250000, 5000, 1000000, -50000 would do: 1. time 5000 : SYNC0 #1 2. time 255000 : SYNC0 #2 3. time 505000 : SYNC0 #3 4. time 755000 : SYNC0 #4 5. time 955000 : SYNC1 #1 6. time 1005000 : SYNC0 #5 7. time 1255000 : SYNC0 #6 8. time 1505000 : SYNC0 #7 9. time 1755000 : SYNC0 #8 10. time 1955000 : SYNC1 #2 11. time 2005000 : SYNC0 #9 ... Note that the SYNC0 pulse timing is the same but we've moved SYNC1 so it happens 50µs before the next SYNC0 pulse instead of 50µs after the previous one. (This also made the sync1 cycle time parameter look like its actual cycle time.) What values are needed for each slave should be given in the slave's documentation -- they're all different, depending on what actions the slave performs on each SYNC event, and whether it needs some time allowance for capturing or processing delays. And, of course, what SM cycle time you want to use. But yes, essentially the "sync1 cycle time register" is the delay between the first SYNC0 and the first SYNC1. Depending both on the dividend and the modulo of this vs. the SYNC0 cycle time it creates the pulse trains for both, but the numbers can be quite confusing at first glance. The diagram from the ESC datasheets demonstrates this; you can also read more detail about it in ETG1020 "Synchronization", in particular the part about "subordinated µC cycles". (Although parts of that might end up being more confusing than helpful.) A simple rule of thumb (demonstrated above) is that if your sync1_shift is not negative then the sync1_cycle needs to be one sync0_cycle less than you think it "ought" to be, but if the sync1_shift is negative then you can set sync1_cycle to the "real" value. Although I did misspeak a bit earlier. The sync0 shift is not directly passed to the slave; it's used to calculate a value for the "Start Time Cyclic Operation" register (which is analogous to sync0 shift, but not quite identical) based on when the master is intending to send the first SM packet. (I've never been entirely clear on the relative shift between the SM packet and the SYNC0 since it hasn't mattered for my slaves, but I *think* the expectation in all of the above is that the SM packet arrives at around time 0, 1000000, etc, allowing for master jitter. So you may need to configure the sync0_shift and/or sync1_shift based on your maximum jitter.) Gavin Lambert Senior Software Developer COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand Switchboard: +49 2630 96520 | https://www.tomra.com The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication. -----Original Message----- From: Tom Wong-Cornall <t...@wongcornall.com> Sent: Friday, 1 November 2019 12:33 To: Gavin Lambert <gavin.lamb...@tomra.com> Cc: Albert Chimeno garcia <chim...@msn.com>; etherlab-users@etherlab.org Subject: Re: [etherlab-users] RV: AX5000 fault synchronism 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
