Am 30.09.2013 um 22:35 schrieb Chris Radek <[email protected]>: > On Mon, Sep 30, 2013 at 09:57:20PM +0200, Michael Haberler wrote: > >> - there is likely interaction from the lower _into_ the upper half >> of the motion threads (for instance, an operation causing >> replanning like feed override), meaning lookahead planning and >> segment execution are rather tightly coupled > > If you know the max feed override ahead of time, then changing feed > override does not have to require a re-plan.
I cited feed override just as an example of any upcall-type (inter-layer) interaction or communication requirement which suggests tight coupling of layers. if you redact away that single example by say handling f/o such that replanning is not required, then _that_ particular requirement goes away, meaning that particular processing step can be viewed as a pipe design with no feedback required. That is for example what your naive cam and cutter radius comp code does right now - treating processing as a pipe with no backup option; however there is a direct connection to a current restriction - no tool dia change during pause. That is one example of desirable upcall interaction where that particular choice gets in the way. We discussed all this a while ago in the 'virtual paper tape' thread; it's the same theme. The gist was: decisions in canon bind too early, there is no way to redo them cleanly anymore, and moving functions forward to the motion upper half is key in making the overall structure more flexible; for instance, moving offset application. Even if moving offset application is possible, it will be very hard to move say CRC as long as the motion upper half must be considered as being in-kernel worst case. The same applies to changes to the planner. > >> I think canon should be viewed as an interface (API) into motion, >> but not part of any motion tasks proper; the reason why some >> functionality exists within canon which could be part of motion is >> more due to restrictions of the motion design, not because canon >> is such a great place to have that functionality in > > I don't understand your objection. What I call the canon level we > might instead call "the last nonrealtime layer before we send > messages to the first realtime layer" - that's a fine place to put > big calculations and I don't see why you think it's hard to link in > a library or whatever. Let me put it this way - I think the feature accretion in canon sort of happened because it was the last safe place to use, say, C++, as you say. Or anything else not amenable to a kernel environment. I dont blame anybody for going that route, but I dont buy the suggestion this being part of a well thought out design - I suspect it just happened because of convenience. If you view the task at hand similar to a shell command where several programs are connected by pipes, then it doesnt matter much where you place the steps, and how early you bind objects, like offsets or diameter. However, IMV that blueprint is a bad model for the motion pipeline - in fact every single restriction with doing anything during pause stems from the fact that way too many decisions have been made too early, and in a way which cannot be backed up - there is no way for upcall type interaction into canon, and that is why any attempts at say doing change-tool-dia during pause, or change-offset-during-pause are doomed to fail in the current functional allocation. That is the consequence of using canon as a warm place where things are easier to do than in motion-command-handler. And that is why I recommend strongly against any more of usage of this warm but unsuitable place for code which should be somewhere else. All we will get is more of the type of restrictions which we already have with 'backing up the queue', as JMK's wiki article put it. > I do not understand why you are intent on breaking out part of > motion - either way there has to be message-receiving code, no?? yes, messaging will remain the interface, but thats not why I am 'breaking out part of motion' (which I'm not) what I suggest is to use the paradigm set out by halstreamer/halsampler which will result in a more flexible environment for motion-command-handler which will obviate the need to graft code into canon where it doesnt belong what you get as a side effect is that normal userland IPC can be used to talk to this component, even NML if one were to use it, meaning lots of single-purpose code like taskintf.cc and usrmotinf.cc just goes away a second order side effect of using an existing API like NML or zeroMQ will be that you suddenly can talk to the think from any code being able to talk that API, which are lots - meaning if somebody wants to talk to motion say for a non-CNC type motion application, that suddenly becomes possible because it moved to a standard interface >> My biggest concern would be this: >> >> if you set out to do a strictly incremental improvement within the >> current motion design (a single RT component with two sequentially >> invoked RT thread handlers), then you will import the baggage of >> restrictions this structure implies. That in turn makes it likely >> some of the advanced code has to move to a less-than optimal >> place, and that has happened in the past. > > Sure but the upside of an incremental improvement is you don't > blossom the project into one of intractable size and give up, and I propose to reuse an idea here which has been in the LinuxCNC code base since 2006 (halstreamer) - that certainly doesnt go under the headline 'unproven research' or 'feature bloat' Think it through, I'm sure you will see the upside of the idea. The only thing 'new' here is to apply the idea to motion. - Michael ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
