From: Robert E. <rw...@gm...> - 2013-10-01 19:24:13
|
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 <ma...@ma...>wrote: > > Am 30.09.2013 um 22:35 schrieb Chris Radek <ch...@ti...>: > > > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > |