Hi Graeme, Thanks for the patch, it works well...
Philippe > Le 21 mai 2018 à 01:19, Graeme Foot <graeme.f...@touchcut.com> a écrit : > > I would propose the attached patch (completely untested). > > This allows the sync1 offset to be used in a fashion compatible with any > existing codebase (hopefully) by adding the sync1 cycle time together with > the sync1 shift time, then splitting them out based on the sync0 cycle time. > The only braking case I can think of is if someone has used a sync1 shift > parameter, not noticing that it is currently not doing anything. > > It will also handle a case where the combined time, that will be passed to > register 0x9A4, will be negative (logging a config error). It will also > handle a case where the sync0 cycle time is zero (not sure if this is allowed > with a non-zero sync1 cycle???) and set up the dc to set the sync0 cycle time > instead, adjusting the sync0 shift time by the sync1 shift time. > > Philippe, in your case you would then call: > ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 0, 1000); > > or (for backwards compatibility) > ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 1000, 0); > > > Graeme. > > > From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf > Of Philippe Leuba > Sent: Friday, 18 May 2018 8:11 PM > To: Gavin Lambert <gavin.lamb...@tomra.com> > Cc: etherlab-users@etherlab.org > Subject: Re: [etherlab-users] Slave DC start time calculation > > Good idea, this should work for different kind of slaves and did not break > backward compatibility. > > How to proceed now ? > > Philippe > > On May 18, 2018, at 7:24 AM, Gavin Lambert <gavin.lamb...@tomra.com> wrote: > > I don’t think it makes sense to start using the sync1_shift_time parameter, > as that would introduce incompatibility with other code (that perhaps hasn’t > upgraded to that build yet, or hasn’t noticed or doesn’t care about the > change in start time), and introduce some additional ambiguity. > > In theory (completely untested air code) something like this might be more > correct: > > cycle = sync0->cycle_time + sync1->cycle_time – (sync1->cycle_time % > sync0->cycle_time); > > From: Philippe Leuba [mailto:ple...@swissonline.ch] > Sent: Friday, 18 May 2018 16:34 > To: Gavin Lambert <gavin.lamb...@tomra.com> > Cc: Graeme Foot <graeme.f...@touchcut.com>; etherlab-users@etherlab.org > Subject: Re: [etherlab-users] Slave DC start time calculation > > Hi Gavin, > > Thanks for the detailed explanation, this explain why the code is like it is. > This works for slaves that are doing oversampling but not for mine that just > want to shift the SYNC1 a bit. > > Now if we want a solution working for all kind of possibles slave > configurations we will need to use the sync1_shift_time parameter of the > ecrt_slave_config_dc into the loop... > > What do you think ? > > Philippe > > On May 18, 2018, at 5:15 AM, Gavin Lambert <gavin.lamb...@tomra.com> wrote: > > The SYNC1 Cycle register (0x09A4) is a little weird; it acts as both a cycle > and shift in one register, depending on the value of the SYNC0 Cycle (0x09A0). > > Where SYNC0 Cycle is X and SYNC1 Cycle is 0, SYNC0 and SYNC1 occur at the > same time – thus same cycle, no shift. > Where SYNC0 Cycle is X and SYNC1 Cycle is less than X, SYNC1 occurs at (SYNC1 > Cycle) ns after the SYNC0, but otherwise at the same cycle rate – thus it > acts as a shift. > Where SYNC0 Cycle is X and SYNC1 Cycle is equal to X, SYNC1 occurs at every > second SYNC0 – thus it acts as a 2X cycle with no shift. > Where SYNC0 Cycle is X and SYNC1 Cycle is equal to 2X, SYNC1 occurs at every > third SYNC0 – thus it acts as a 3X cycle with no shift. > Where SYNC0 Cycle is X and SYNC1 Cycle is greater than X but not an exact > multiple, it acts as a combination of cycle and shift as above. > > (Under the hood, it always does behave as a shift that fires exactly once > non-overlapping offset from the SYNC0 pulse. Or to put it another way, SYNC0 > starts the timer but doesn’t reset it if already running, and it fires SYNC1 > once when the timer finishes.) > > The ecrt_slave_config_dc method essentially just sets the cycle values into > the registers directly, while using the sync0_shift to calculate the overall > DC start time relative to the master cycle. The sync1_shift parameter is > ignored and should always be 0 because there’s nothing it can actually do > with it. > > Exactly what these mean is slave-specific; some slaves want a simple shift at > the same cycle rate because they use one to control output timing and the > other to control input timing. Other slaves might want a subordinated cycle > (SYNC1 occurring at the master cycle rate, SYNC0 occurring more frequently) > because they want to oversample inputs. Or there can be a number of other > scenarios. The slave documentation should tell you what settings you need > relative to your master cycle. > > For what it’s worth, I do have a subordinated slave – it uses > ecrt_slave_config_dc(sc, 250000, 100000, 750000, 0) to make SYNC0 pulse every > 0.25ms, SYNC1 pulse every 1ms (yes, 1ms, not 0.75ms), and both to be offset > from the 1ms master cycle by about 100us – although that’s a little arbitrary. > > I assume the change was probably motivated by this sort of slave > configuration (since it does extend the “true” cycle time of the slave, from > a certain point of view), but simple addition is probably wrong when a > non-multiple sync1 cycle time is used to introduce any kind of shift into the > mix. > > From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf > Of Graeme Foot > Sent: Friday, 18 May 2018 13:03 > To: Philippe Leuba <ple...@swissonline.ch>; etherlab-users@etherlab.org > Subject: Re: [etherlab-users] Slave DC start time calculation > > Hi, > > This piece of code is getting a start time that is in sync with the initial > app time from a multiple of the sync0/sync1 cycle times, adjusted by the > sync0 shift time. > > https://download.beckhoff.com/download/Document/io/ethercat-development-products/ethercat_esc_datasheet_sec2_registers_2i7.pdf > says the sync1 cycle time is the "Time between SYNC1 pulses and SYNC0 pulse > in ns". > > However > https://infosys.beckhoff.com/english.php?content=../content/1033/tcsystemmanager/reference/ethercat/html/EtherCAT_DistributedClocks.htm&id= > (Twincat DC settings) and the information for my yaskawa drives are saying > that the sync1 cycle time should be a multiple of the sync0 cycle time, and > the sync1 offset is the offset between the sync0 and sync1 interrupts. > > The master code doesn’t even look like it uses the sync1 shift time, and > information from my Yaskawa slave says it's sync1 cycle time is readonly and > matches the sync0 cycle time. > > > So: > - It looks like the first documents registers 0x09A4:0x09A7 should actually > be called sync1 shift time. > - It does not look like there is currently any slave support for a different > (from sync0) sync1 cycle time. > (anyone got a slave out there that does?) > - The EtherLab master should not be using sync1 cycle time in the calculation > you mention below. > - The EtherLab master should be sending sync1 shift time to 0x09A4:0x09A7 > instead of the sync1 cycle time. > - TwinCAT is probably using its cycle time "multiple" parameters to figure > out how often to send the PDO requests for each slave (just a guess). > > > In your case, set the second to last parameter to zero, i.e.: > ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 0, 0); > > You have already adjusted the sync0 shift time (third to last parameter) > anyway. > > > Regards, > Graeme. > > > > From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf > Of Philippe Leuba > Sent: Friday, 18 May 2018 7:11 AM > To: etherlab-users@etherlab.org > Subject: Re: [etherlab-users] Slave DC start time calculation > > Hi, > > I have changed how to calculate the slave start time by taking only the > sync0->cycle_time as cycle time. > The results is good and I can see in the log that the 'remainder' is almost > the same for all slaves. > > @Florian: Why did you did this change on 2016-09-16 ? > > Best regards > > Philippe > > On May 16, 2018, at 6:22 PM, Philippe Leuba <ple...@swissonline.ch> wrote: > > Hi All, > > I can not understand how to configure correctly my slaves with the > ecrt_slave_config_dc() function. > > I use nine EL7211-9014 servo controllers and the XML declarations is: > > <Dc> > <OpMode> > <Name>DC</Name> > <Desc>DC-Synchron</Desc> > <AssignActivate>#x700</AssignActivate> > <CycleTimeSync0 Factor="1">0</CycleTimeSync0> > <ShiftTimeSync0 Input="0">30000</ShiftTimeSync0> > <CycleTimeSync1 Factor="-1">0</CycleTimeSync1> > <ShiftTimeSync1>1000</ShiftTimeSync1> > </OpMode> > </Dc> > > SYNC0 and SYNC1 should be fired at each cycle. > > My realtime cycle is at 500us, so initially I used: > > ecrt_slave_config_dc(sc, 0x0700, 500000, 30000, 1000, 0); > > but I sometimes faced some hiccup on some motor movements (almost always on > the same motor, but sometimes not), most probably due to frames late > regarding SYNC events, so I increased the sync1_shift to half of the cycle > time: > > ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 1000, 0); > > This help, but I’m still not convinced that it is correct. > > How can I debug this, I did not see any error on slaves COEs 1c32 or 1c33 ? > > Startup debug messages are the followings: > > EtherCAT DEBUG 0-12: Checking for synchrony. > EtherCAT DEBUG 0-12: 19 ns difference after 1 ms. > EtherCAT DEBUG 0-12: app_start_time=64456682505935 > EtherCAT DEBUG 0-12: app_time=64460192975876 > EtherCAT DEBUG 0-12: start_time=64460292975876 > EtherCAT DEBUG 0-12: cycle=501000 > EtherCAT DEBUG 0-12: shift_time=250000 > EtherCAT DEBUG 0-12: remainder=263941 > EtherCAT DEBUG 0-12: start=64460293462935 > EtherCAT DEBUG 0-12: Setting DC cyclic operation start time to 64460293462935. > EtherCAT DEBUG 0-12: Setting DC AssignActivate to 0x0700. > - > - > - > EtherCAT DEBUG 0-13: Checking for synchrony. > EtherCAT DEBUG 0-13: 9 ns difference after 1 ms. > EtherCAT DEBUG 0-13: app_start_time=64456682505935 > EtherCAT DEBUG 0-13: app_time=64460854977928 > EtherCAT DEBUG 0-13: start_time=64460954977928 > EtherCAT DEBUG 0-13: cycle=501000 > EtherCAT DEBUG 0-13: shift_time=250000 > EtherCAT DEBUG 0-13: remainder=444993 > EtherCAT DEBUG 0-13: start=64460955283935 > EtherCAT DEBUG 0-13: Setting DC cyclic operation start time to 64460955283935. > EtherCAT DEBUG 0-13: Setting DC AssignActivate to 0x0700. > > I’m really surprised that the remainder can be so different, so I looked in > the source code and can not understand the logic: > > // set DC start time > start_time = master->app_time + EC_DC_START_OFFSET; // now + X ns (X > being 100000000 = 100 ms) > > if (sync0->cycle_time) { > // find correct phase > if (master->has_app_time) { > u64 diff, start; > u32 remainder, cycle; > > diff = start_time - master->app_start_time; > cycle = sync0->cycle_time + sync1->cycle_time; > remainder = do_div(diff, cycle); > > start = start_time + cycle - remainder + sync0->shift_time; > > Why the cycle is the sum of the two sync->cycle_time, in my case 501000, > should not it be: sync0->cycle_time (500000) ? > > This was changed on 2016-09-16, but It seems it was right before. > > I can see that sync0->cycle_time is written to register 9A0 (500000) > and sync1->cycle_time is written to register 9A4 (1000), this is correct. > > It seems to me that the sync1_cycle parameter of the ecrt_slave_config_dc() > is handled as as sync1_shift, this is really confusing. > > Is it normal, can someone explain this ? > > Philippe > _______________________________________________ > etherlab-users mailing list > etherlab-users@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-users > <dc-sync1-offset.patch>
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
