Chris, Thanks. I think I can just sit there and wait. The code snippet I provided already runs in its own thread, so blocking that thread on waits is not a problem. The real issue is that I do not want to pop (i.e. latch) the first element off the queue (a list technically which sorts based on priority), until the entire new program launch sequence completes successfully. Otherwise that element should remain as the first item in queue until whatever interlock or error that prevented it from running is cleared. Which means that the sort order of the queue could potentially change in the time it takes to go through this sequence.
That can be addressed by changing the priority of the first element in queue to the highest possible priority, and locking out delete and change priority once it has been promoted to this priority (i.e. committed as the next job to run). I was aware of emcCommandWaitDone, I just wasn't convinced that doing MDI calls and then blocking the update thread was really the best way to issue these commands. Thanks again, Eric On Wed, Apr 08, 2009 at 10:17:39PM -0400, Eric H. Johnson wrote: > Hi all, > > My first question is whether effectively doing MDI calls is the best > way to do primarily the motion commands. And the second is, do I have > to setup something like a state machine to wait for each of the > commands to complete before issuing the next command. Yes I think MDI is the right way to do these kinds of setup commands. Isn't it just emcCommandWaitDone() that you need? But if your code can't just sit there waiting, you have to get fancier. halui has some complexity in it because it wants to wait for the mdi to complete, but also wants to continue polling the inputs, so for instance the user can abort the move. You might look at halui for ideas. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
