Gene reported that 'queuing MDI commands in master does not work since MDI tab is greyed out while last command running' (btw a bug report would still help if to aggregate tracking)
this is due to http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=81f105b477699060d6c721a06034aceea31cb964 which I recently added I wont be able to do anything about it before end of May, so: Please do NOT revert this patch. It fixes a real bug, and the 'Axis MDI queueing feature' worked accidentially because of that bug, because Axis assued the interpreter idle when it wasnt. Also, I suggest not to 'fix up Axis to get MDI queuing to work again'. The proper solution to the problem is to respect the running state also in MDI in Axis, queue MDI commands within Axis and dequeue the next command when interpreter state returns to idle. The previous code has the following race condition: - Interpreter *input* has no queue, and no semaphore to protect a running program against a second invocation of the interpreter with an MDI command. - Calling the interpreter is conditional on interpreter state tracking in task. Note you cant start a another program while one is running. you need to abort so state reverts to idle before you can do that. In auto state tracking works, and so does prevention of multiple invocation. Axis honors that. - Interpreter state tracking in task was broken for MDI (reported as always idle), so the condition to prevent serial invocation of the interpreter without the previous command/oword sub finished was broken as well - the reason why 'MDI queueing from Axis worked' was: task would blindly call the interpreter disregarding the current interpreter execution state - The violating condition will likely not show up when you just input simple blocks (G/M..), the reason is that interpreting a block is almost atomic. - as soon as oword sub with a queuebuster operation is called from MDI, and another MDI command is 'queued', the second MDI command is parsed and will happily overwrite the block which is waiting for the queuebuster to finish, plus possibly modify the interpreter state inadvertantly. - calling oword subs from MDI is a recent feature, so it very likely that scenario hasnt been hit yet to see it, just turn on debugging so you can see interplist commands. this will show the sequencing of calls to the interpreter right there. - Michael ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
