On 7/15/2013 10:28 AM, John Kasunich wrote: > > 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). I'd like to think of continuous jog as a gui state rather than a machine state. I'd think of the gui issuing consecutive short job commands as long as the jog button is held. (I recognize that there is an issue of how many are outstanding at a time, how fast the jog is, how long each step is, and so on). Of course, it wouldn't matter then if the command were from a wheel or a button.
One important plus of this would be the ability to jog in any arbitrary direction; not just aligned with a machine axis. On my list of neat stuff would be to "jog" through a program a line (or piece of a line) at a time. That might work in both the forward and backward directions. > > 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. > > ------------------------------------------------------------------------------ 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
