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

Reply via email to