On Mon, Jul 15, 2013, at 03:31 AM, Michael Haberler wrote: > > Am 15.07.2013 um 05:57 schrieb Chris Morley <[email protected]>: > > > 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.
For the most part this discussion is over my head, but I do want to put my two cents in here. There definitely _is_ a difference between MAN and AUTO/MDI, beyone simply the source of the motion commands. The list of supported commands is also different. AUTO/MDI mode commands include things like "move line" and "move arc" - they have a specific endpoint, and when that point is reached the command is "done" and the next one can be fetched from the queue. MAN mode has some commands like that - for example incremental jogs which move a fixed distance. But others, like continuous jog, are different. A jog continuous tells motion to start moving and keep moving until told to stop (which happens when the user releases the jog button). As I think about it, this might be a weak example, because jog continuout is actually implemented as a move with an endpoint. The endpoint is the far end of the axis, with the expectation that a stop command will arrive first. However, it still is not a command that can be arbitrarily queued, because the next command wouldn't be taken from the queue until the present one is "done", and the jog continuous wouldn't be "done" until it reaches the end if the axis. Jogs rely on the stop command going _around_ the queue. An even more obvious case is jogwheels. Wheel jogging doesn't involve task or GUI or the motion queue at all. The jogwheel is directly connected to motion, and the flow of information from the wheel to the motors is entirely in real-time. It must be, in order to have smooth jogs - we tried non-realtime jogwheels early on, and the results were terrible. If the mode is MAN, then a change in jog wheel position drives a change in axis position. If the mode is AUTO or MDI, a change in jog wheel position is ignored. One source of complexity is deaiing with the case where a jogwheel is turned on the realtime side at the same time as a jog command from task is active. Likewise, what happens if a keyboard jog is initiated while a wheel jog is already in progress? I know there is code in motion to handle that - I wrote it, although I don't remember the details. This makes me wonder if keyboard jogs could/should be moved out of the AUTO/MAN queue, and instead use the wheel jog mechanism? Hitting a jog key would move the "jogwheel" position, just like turning the wheel. And just like turning the wheel, the actual movement would happen or not happen based on the current mode of the machine. It wasn't designed that way in the first place, because keyboard jogs predate wheel jogs by many years (wheel jogging was added after EMC2 was working.) But now that the realtime wheel jogging mechanism is present, it might be cleaner to use it for all jogs. -- John Kasunich [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
