Am 15.07.2013 um 05:57 schrieb Chris Morley <chrisinnana...@hotmail.com>:
> > >> From: mai...@mah.priv.at >> Date: Mon, 15 Jul 2013 00:01:34 +0200 >> To: emc-developers@lists.sourceforge.net >> Subject: Re: [Emc-developers] discuss: Why do we have MAN, MDI and AUTO >> modes. >> >> Chris, >> >> I have been asking myself this question too. I find no good reason for it >> either. >> >> My current theory is this: the distinction exists because of: >> >> 1. a conceptual mixup of an input method, and a machine state >> 2. the lack of concept of a concept of what is called a 'compilation unit' - >> a unit of interpreter processing if you will >> 3. (unsure) failure to spell out clearly what the difference in execution >> semantics between MDI actually is >> > > Well traditionally we had 3 states for good reason I suspect. > > Manual: > literally was doing things manually, aside from jogging, the functions could > be outside > computer control (direct relay manipulation) > > MDI > same as AUTO except it waits for each command to be entered and then acts on > them. > Ignore manual controls > > AUTO: > Read from a file (memory/tape reader) commands and run them all. > Ignore manual controls. > > This was at a time when computer power was at a premium. > Well it's not anymore. > > When you look at this description it's easy to see that blending them together > would be pretty easy conceptually. > > MDI and AUTO are the same other then where they get their info from. > Aside from jogging, I think every manual control has MDI equivalents. > In fact some manual controls are done in MDI. > > What if we got rid of 'modes' and relied on interpreter signals to decide > if controls work or not. > eg. if the interpreter is 'idle' manual controls would be usable on the GUI > and/or > MDI commands will execute. That is possible, but I would suggest a different approach to mode switching - not at the interpreter level, but a motion primitive: I view MAN vs AUTO/MDI being in effect separate input channels to motion. You can feed either channel with manual motion commands, or interpreter generated - there's no conceptual difference. The restriction of the current setup kicks in if you want to mode switch and the interpreter is not idle (technically the restriction is - the single motion queue cannot be guaranteed to be and remain empty from the 'current feeder' and hence it is unsafe to switch) - this is why we have the task nazi task watching mode and the motion queue and denying the switch; so you will inherit the current behaviour - cant switch as long as the interpreter isnt known to be done . That is very restrictive. the whole picture changes if you support several motion input queues and a primitive to switch between them - there is no need to deny manual commands just because the interpreter isnt done, but motion is in a stopped state; the alternate queue can be fed by manual or interpreter-generated commands as needed, and commands in the primary queue just sit there waiting for that queue to be resumed. What needs attention is restoring state (like a move back to where one left off) when switching back to auto (see Stuarts reply to my followup question - others were in the same spot already). This is exactly what my jog-while-paused modification does - employ a alternate motion queue and a switching mechanism: http://tinyurl.com/pb3sjj7 (it isnt a particularly general solution to the 'do something while paused' problem, but obviously a desired one because several folks requested this be merged), and it points in the right direction. --- taking a step back, I think it's an example of a valid problem being addressed by means in the wrong place: it is important to be able to switch input sources to motion, which is all what MAN/MDI/AUTO is really about. However, the current solution tries to achieve this with a broker task watching inputs and modes, and scheduling 'permitted' commands; necessarily falling on its face as soon as the queue between task and motion is not empty. It's done in the wrong place - as soon as you have several queues, and a switching method, the requirement to block certain command at the task level goes away. So - what MAN/AUTO/MDI currently is: a state variable managed by task. What it should be: an input queue selector in the component processing motion commands. - Michael > We have these signals already. > > If we created a 'Jogging enabled' MDI command, this concept almost works as > is. > Conceptually anyways. > > Chris M, Thinking out loud again. > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
