Mere moments ago, quoth I: > On 28 April 2017 11:59, quoth Graeme Foot: > > 2) Your 0054 patch successfully moved the slave sdo request processing > > from the master fsm's idle state to be called every cycle of the master > > thread. > > However, I have my Linux environment set to run at 100Hz, so this > > thread would only fire once every 10ms. Each SDO read/write request > > would take approx. 30ms to complete. I didn't want to change Linux to > > run at 1000Hz so I > > created patch "etherlabmaster-0010- > > allow_app_to_process_sdo_requests_from_realtime.patch". > > Maybe I'm missing something about how the RTAI version works, but all I did > was to move the logic from inside fsm_master to inside fsm_slave; AFAIK > both of these execute on the same thread (either the master IDLE or master > OPERATION thread). This is independent of the application realtime loop > either way, so this should not have changed how frequently they run; it just > allows multiple slave requests to run in parallel rather than forcing them to > execute sequentially, so it should be a net performance gain. > > Though it does seem reasonable in your use case to want to run the slave > FSMs more often. I don't see how you could do that safely, though -- you > can't run ec_master_exec_slave_fsms outside of the master_sem lock, and > your RTAI task might interrupt Linux while it's still holding that lock, which will > deadlock your RTAI task.
Are you configuring with --enable-hrtimer? After having a quick look at the code, I can see a potential performance degradation from the patch if you aren't using it (or did enable it but didn't call ec_master_set_send_interval with an appropriate value after activating the master). Perhaps you could try enabling that instead of using your patch and see if it helps? _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
