Hi Anders, Those are all good points, so I'll try to address them one by one here:
High maximum FO: the situation you describe could happen. The tradeoff with a high maximum override is suboptimal performance, since we would essentially be scaling down by 50x from the planned path in that scenario. Unfortunately, I'm not sure there is a way around this without implementing queue replanning. As Michael mentioned in another thread, it seems like it will be messy at best to do in the current system. So, if replanning is difficult to do well, then one answer is to just accept this difficulty as a known issue, with the intention to fix it as soon as the infrastructure is ready. I will look into what it will take to do replanning entirely within the motion module in the meantime. Blend tolerance: the lookahead optimization is only changing the upper bounds on the feed rate for each tc / blend. tcRunCycle can easily handle lower speeds, as the motion wi just take a bit longer. Similarly, the size of the blend arc depends on the blend velocity (as it does now). So, if we are running at a lower speed in a particular blend, the arc will be proportionally smaller. I saw this as acceptable and even desirable behavior if we consider it only as a tolerance problem (i.e. less is always better if we can get it). However, if people are using blends to create a desired smooth shape, then this behavior is bad. Engraving is a good example, aggressive blending will smooth out a Toolpath of linear segments. If someone wants to run an engraving cut slower, the result will be different due to this. This raises is an important question for everyone: do you prefer the smallest possible blend (slower speed->smaller arcs), or a consistent size blend (same blend arcs irrespective of speed)? Kinematics: my intention was to handle the other axes in a similar way that the current planner does, namely as independent "linear" axes. I though that, at least for 4th axis work, the CAM program does its own inverse kinematics based on the configuration you specify. That way, the actual g code lines are essentially jointspace commands, needing no IK. This is a good thing if your 4th axis can be unbolted and reoriented. The problem I can see with implementing lookahead for general 6 DOF task motion is that you need the joint space motion to predict torque and speed limits. So, any trajectory planner needs to run the ik solver over the whole motion ahead of time, sampling the solution to find peaks in speed and acceleration. This is way more calculation than the trivial case, where we can tell everything we need to know from a few motion parameters. I need to study the kinematics code further to be sure, but it seems like this kind of motion planning is easier done as preprocessing. Still, I'd like to make this as generally useful as I can. I'll take a closer look at the arbitrary kinematics planner to see what differences there are. Thanks again for all your input! Rob On Oct 3, 2013 6:29 AM, "Anders Wallin" <anders.e.e.wal...@gmail.com> wrote: > > 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. > > > > Blending couples feedrate to machining tolerance. You should think hard > about what is reasonable behaviour when defining a max feed-override in the > INI file, and when the user actually dials down or up the feed-override on > the machine. > Example scenarios: > - user got his INI file from a friend. Friend likes max FO= 9000%. Now why > does the planner do such a bad job of blending motion when user wants to > run all his programs at FO=100% and a tight tolerance? > - user dials-down feed-override to 20% in a tricky/critical part of the > toolpath. Is blending tolerance simultaneously automatically improved, or > do we just run the blended path (planned for 100%, or worse still 150% > feed) at a slow rate? > - user first programs G64 P0.01 (or whatever the syntax for blending > tolerance is). We want a part with 0.01 (mm or inch, you choose) tolerance. > Now we are also in a hurry, so dial up the feed-rate to 200%. Does that > mean LinuxCNC will interpret this user input as really meaning 0.02 > tolerance? Or will it keep to the 0.01 tolerance and ignore the FO=200% for > parts of the toolpath where it is not achievable? > > You mentioned focusing on trivial (3-axis?) kinematics at first. For some > users that is fine, but others will want 4-axis or nontrivial kinematics. > Can the new coding-effort be done in such a way so that switching between > the current 6-DOF arbitrary-kinematics planner and the new planner is easy? > > Anders > > ------------------------------------------------------------------------------ > 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-developers@lists.sourceforge.net > 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
