Hi Chris and Michael, On the issue of the feed override specifically, I agree with Chris that large overrides are probably not necessary. Feed rate override on a CNC mill (for me anyway) is more of a debugging tool for G code to get feeds and speeds right. Drastic global speed increases after the planning is done are not a good idea because not all feed rates should scale at the same rate. Think plunge feed rates, feeds on small tools, etc. Therefore, a fixed maximum override is a good solution to avoid replanning.
A good answer to the inevitable user concerns could be to make that maximum configurable. The user could set their own maximum feedrate override in a configuration file. If the user wanted 150%, for example, then the planner would always calculate the maximum speeds using that override, then scale everything down to 100% for normal operation. The tradeoff here is that programs with both fast and slow feeds together will see the slower overall performance when running at 100% than a user who selects 120% or even 100%. It's up to the user then to decide if they prefer more override control, or more optimal feeds. Also, based on this wiki page, it seems like implementing replanning in general is a tricky problem, even without worrying about lookahead. http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WhyManualWhilePausedIsHard To Michael's points, I agree that an overhaul of motion would make a lot of this development easier, and enable much more flexibility in how the motions are controlled. Unfortunately, overhauling everything at once is a bit too ambitious for my first LinuxCNC improvement. I'd prefer to gain experience in LinuxCNC by implementing lookahead in the current framework (within the RT side), before trying to tackle a total overhaul of the motion system. After developing a workable solution, I'll be in a much better position to both appreciate the gaps in the current system and implement large-scale improvements. Thanks! Rob On Mon, Sep 30, 2013 at 6:08 PM, Michael Haberler <[email protected]>wrote: > > 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 > ------------------------------------------------------------------------------ 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
