On 16 May 2018 7:30 p.m., quoth Michael Ruder: > I found that ecrt_master_sync_monitor_process() only delivers a "good" > value if I call it between the master_receive and master_send, so I retrieve > the value before I send out again: > > - master receive > - domain process > - save sync monitor progress > - write cached PDO values > - domain queue > - dc sync > - master send > - perform application calcs (writes to PDO data is cached)
Calling ecrt_master_sync_monitor_queue "resets" the sync monitor for the next cycle; you have to call ecrt_master_sync_monitor_process before that (typically near the domain process). As a general rule, "process" always follows "receive" and "queue" always precedes "send". Also, I've noticed an error in my prior post -- you do have to call ecrt_master_application_time immediately prior to ecrt_master_sync_reference_clock (and "ecrt_master_sync_slave_clocks" after both), so these should all be in your "dc sync" block above, as close as possible to "master send". > Is there anything else I need to keep an eye on when doing all the work after > "master send"? Can I safely assume that all TxPDOs from the drive are still > valid after the master send and I can read them after the master send using > EC_READ_*? Or should I save them when I write the cached RxPDOs? In my > test program, it works without caching though. The TxPDOs will remain valid until overwritten by the next call to ecrt_master_receive -- provided that you have not explicitly enabled "overlapping PDOs" for the slave (if you do, network and memory usage is reduced but writing the cached RxPDOs will overwrite the received RxPDOs. Also, not all slaves support that; but it's always disabled by default). _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
