Hi Graeme, hi Gavin, wow, thanks for the great, detailed and quick replies!
This was extraordinarily helpful! I like Graemes suggestion for the cycle very much. I can cope with the delayed PDO sending much better than I could cope with a fixed, rather long wait in my cycle. I modified my test program accordingly, including the move of the application_time call directly before the send call and get a sync error of < 1000 ns (I'd say 200-300 ns RMS) according to ecrt_master_sync_monitor_process(). When I look at the 0x92c registers, I can see that the error is in relation to slave 0 while between slave 0 and slave 1 it is much smaller, around 20-50 ns RMS. Very nice! 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) 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. Thanks again a lot for the help! -- . -Michael _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
