Is there some reason that the MDI window can only have one line of code? Every CNC control that I've touched (3 or so) allow you to enter as many lines as you want in the MDI window.
John On 5/2/2012 8:33 PM, Michael Haberler wrote: > 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 ------------------------------------------------------------------------------ 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
