Hi David, thanks for taking the time to capture ideas and structuring them
Overall, the 'motion queue mux' captures the key idea a few remarks on the document: - 'one source of programmatic motion at a time' - that is certainly what is expected and what task does To summarize where the restriction in the current design comes from: task does the source switching; due to the - single, non-switchable - motion queue it cant switch if there's something underway in same queue. That changes fundamentally if you move the queue switching to the component which processes the queue. "Locking motion to the interpreter while the program runs" is a necessity by the current design. I admit I did make a oversimplification with my statement what the mode switching should be, and JMK rightfully took me up on it. I wasnt suggesting all machine modes should be managed at the motion control level; I wanted to raise attention to the fact that having such a 'canon mux' in place provides lots of flexibility with mode switching. - on the canon layer being a great idea: I have somewhat mixed feelings about that. [this is a bit of a digression] Decomposing constructs of some frontend language into motion-related primitives is a sensible step. I think the decomposition into 'canon commands' and having a rather dumb 'canon command interpreter' sitting in the upper half of motion (control.c) is a questionable design, firmly rooted in a notion that processing and binding must happen as early and deeply as possible because that poor RT backend just doesnt have the cycles do to any better. The days where hardware dictated that design split are long gone, and I think it time to revisit the assumptions. The canon 'queue' thrown in, you have a great 60's design of a single-queued batch processing system, trading 'efficiency' for flexibility. Overall, I think the canon semantics are on too low a level. For an alternative, see for instance the Deltatau PMAC Motion script language (nb: a real language with control structures, expressions and all). I believe it is entirely doable to translate motion languages (like RS274NGC) into say Python and use this as a motion scripting language, meaning some of the processing - and flexibility - can easily move towards the RT backend. The 'VPT' idea Chris Radek and me have been chewing on a bit goes in the same direction: making the 'motion commands' look more like a 'scripted motion language' will go a long way towards removing many restrictions derived from the original design. IOW: canon better be a motion intermediate language, not a sequence of stimuli to a rather primitive FSM. The bang is all there nowadays. Also I note that the HAL runtime support for such a more intelligent motion backend has been in place for a long time: for instance, the halstreamer and halsampler components (actually a cooperative RT and a userland HAL comp) already show how this can be done, although they use a C userland component. One could perfectly replace the upper handler (the motion command interpreter) with a Python HAL comp today, with a rather minimally modified Python HAL module. [end digression] - feed hold, altering GCode internal state that's not how I understand the current feedhold implementation - it works at the tp dequeuing level and the interpreter doesnt know much if anything about it - what is allowed during toolchange as things are now, the toolchange process is basically interpreter-driven; remapping just added new ways to configure the sequencing in the interpreter. What I think the 'toolchange' related discussion revolved about was about changing certain tool properties during program execution, including toolchange, also feed hold. That is where the early binding into canon primitives, and the lack of (re)-processing capability at the motion level come in; if a tooldia change changes offset curve shape, motion cant do anything about it because a) its said and done way before the primitives reach motion b) it lacks the programmability to do even if it could. - Michael --- A semi-related remark from reading the Deltatau PMAC manual: Right now we have coordinated (all joints driven through kinematics transform) and non-coordinated modes; however, the coord mode joint/axis binding is fixed at configure time; and I think (stand to be corrected) it isnt currently possible to mix coordinated and joint moves. PMAC deals with this by defining what they call 'coordinate system' - I understand it to be a instance of a kinematics and joints binding; so you could have a 'coordinate system' which has some joints not be coordinated but still be subject to interpreter control. This abstraction looks like a rather interesting idea to me, in particular as it seems runtime-selectable at the motion script level. A related theme recently has come up in a thread about 3D printers where the extruder seems to not be part of coord motion (or so I understood). Am 15.07.2013 um 20:49 schrieb David Bagby <[email protected]>: > Hi, > This thread caused me to clean up some notes I'd jotted down during > Wichita related to this topic. > In this thread I think that different people are talking about different > aspects of a topic that I think of as "implications of multiple > programmatic motion sources". > > Alas I think about this stuff better with pictures... (unfortunately, > it's a little hard to share text and pics via a text only email list > that does not allow attachments). > So pardon me, but the best I can think of to do is to upload a pdf doc > with pics and ask that you grab it to look at. > www.CalypsoVentures.com/privatedl/LCNC/LCNC_control_mode_distinctions.pdf > > The pics helped me structure how different aspects of this thread > interrelate. > > Michael: I'd also like to know if I have translated reasonably what you > tried to describe via email text. > Kent: thanks for my new vocabulary word of the day: Gedanken - I had to > look that one up - only to find that is what I was doing with the > notes... ;-) > > Comments are welcome. > > Dave > > P.S. I'm also happy to provide the base doc for the pdf if anyone > prefers to comment by editing it directly to create red lines (MS office > sources). > > On 7/14/2013 2:00 PM, Chris Morley wrote: >> This has been bugging me awhile. >> Why does linuxcnc force three modes? >> I understand it's a hold over from industrial machines. >> >> > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
