Am 03.05.2012 um 13:15 schrieb John Thornton: > 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.
There's no conceptual problem. The current interpreter has a function 'execute()' which takes a string as argument and executes it 'in MDI mode' (whatever that means - really a single line string input) note I proposed handling proper queuing of MDI commands by modifying Axis to have a queue of MDI commands, and feed them to task one by one within the interpreter state constraints. if that is done, there is no reason why the input window couldnt be multi-line - the UI would read multiple lines from the input window, and add each line to the UI-side queue. What probably needs to be reconsidered is the relation between 'greying out the MDI tab' and interpreter state != idle, because as things stand now the MDI tab would grey out as soon as the first MDI command is executed, and remain so until the last (btw exactly as running in auto). I guess the solution to this is to link the greying-out to a different condition in Axis, for instance MDI-queue not full, if it were to have a limited size). I forgot to mention that an interpreter abort should flush the UI side MDI queue to prevent damage - Michael > > 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 ------------------------------------------------------------------------------ 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
