I'm a bit confused by Reinhard's views. If you Use an F command F100 and you apply a feed override of +10%, surely then the machine is allowed to travel at F110? In that instance the F code is overridden and the velocity may be higher than the F command by up to 10 units.
I thought the trajectory planner takes the F command including any feed overrides (lets call this commanded velocity) and calculates motion.current-vel for that particular segment having regard for the acceleration limits set in the ini file. If the segment is not long enough to achieve the commanded velocity with the .ini acceleration constraints, then motion.current-vel will be limited. Thats pretty basic trapezoidal motion stuff. We spent a fair bit of time working though this with plasma machines (where knowing the commanded velocity is critical) and I don't recall seeing an instance where commanded velocity was exceeded. BUt that was a while ago Rod Webster *1300 896 832* +61 435 765 611 VMN® www.vmn.com.au On Wed, 1 Apr 2020 at 13:10, Reinhard <reinha...@schwarzrot-design.de> wrote: > Hi, > > I'm thrilled that improving synchronization has become so much interest :) > > On Dienstag, 31. März 2020, 18:10:37 CEST andy pugh wrote: > > On Tue, 31 Mar 2020 at 06:46, Reinhard <reinha...@schwarzrot-design.de> > > wrote: > > > The testcase (3Dchips.ngc with different f-words) shows, that f-word is > > > not bound to the motion segments. So I wonder, how the max. velocity of > > > segments is calculated? > > > > The actual velocity and acceleration limits are set in the INI file for > > each joint, axis and the trajectory planner. > > Well, than calculation of motion speed will be wrong in most situations. > > > The F-word is only used at interpretation time to calculate the requested > > velocity for each motion segment. > > > > At execution time this is modified by over-rides and machine kinematics > > constraints. > > But this modification should be allowed to lower speed only. Not to rise > it up. > > > I admit I am puzzled by why you think that having the GUI accurately > report > > the F-word that was used to define the currently-running G-code line is > > important. > > For me it is important, that the GUI reflects the actual machine state. So > everything is important. Whether it is a wrong G- or M-Code or whether it > is > the wrong feed value. > The latter is worse, as it shows, that motion takes the wrong feed limit. > The F-Words are used by calculations of workpiece and tool properties and > the > machine MUST respect it. > The testcase from Chris shows, that the machine does not respect the coded > limits. > > ... and after all: using the GUI - I see the feed value and change the > feed > overwrite to whatever needed. If the GUI shows the wrong values, my action > will be wrong too. > > The mill at work shows the right values - even in single step mode. > I learned to appreciate that information, no matter whether it is the feed > value, the list of active G- or M-Codes and of cause the dtg-values. > All values are displayed when I hit "start" button with feed-overwrite set > to > 0. > The machine does nothing and I have time to validate all settings. > Its very handy to see, what fixture is active, whether radius correction > is > active and so on. > > ... and if linuxcnc could offer the same information level, but can't of > cause > of wrong decisions from past - I'd like to spent work to change it. > > Reinhard > > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
