In LinuxCNC you can specify a tolerance on the G64 command, so the controller sacrifices constant speed to maintain the toolpath within the specified tolerance. e.g. put 'G64 P0.05' at the begining of the G-code and the path will not deviate by more than the P from the true value.
Suppose you set your maximum velocity settings for X and Y both to 1000mm/min, home the machine (so it's at 0,0) then enter 'G0 X100 Y100'. Mach will move both X and Y as fast as it can (as it's a G0 move), so the feedrate you actually get is , assuming the machine can accelerate to that feedrate within the specified distance.
The practical upshot of this is you can specify a feedrate higher than the velocity setting, and get that feedrate in some circumstances.
Same as example 1, except we enter 'G1 X100 Y200 F1100'.
The required speed is 1100mm/min, so the following must hold: , where X and Y are the X and Y axis velocities.
The Y axis must travel twice as fast as X to go in the correct direction (as 200/100=2), so we have
We also have the condition ,due to the motor tuning settings.
From (2), , so substitute that into 1:
(You can also solve this graphically quite easily - which may be more intuitive.)
So the X and Y velocities do not exceed 1000mm/min, yet the machine can in this example cut at 1100mm/min.
In reality, it's probably not a good idea to use this 'feedrate bonus' as it makes the feedrate a function of the direction in which the machine is travelling, so unless you're cutting a single straight line the feedrate you actually get will vary (continuously if an arc move).
Some of us do :) but it's true J is playing with it. It's a nice new toy tho if I could make it work for me..
Dare I ask for a bit more clarification? Dangerous ground, here, perhaps! But here goes...
What I'm not quite sure about here is the difference between G0 and G1. So, a few examples to see if I understand. In all cases, we start at (0,0).
G0 X100 Y100
This is a rapid move at max permitted machine speed. If max X and Y speeds are 1000mm/min, then Mach (or LinuxCNC, I presume) will move each axis at max permitted speed which actually moves the cutter at 1414mm/min across the bed (hypotenuse of right-angled triangle).
G1 X100 Y100 F1000
Mach/LCNC calculates the speed needed for each axis to achieve an actual cutting speed of 1000mm/min along the cutting path, which translates to a speed along each axis of 707mm/min, well within max permitted limits. So you could write G1 X100 Y100 F1400 and actually cut at that speed.
What Jonathan has said is that (using these figures) the max cutting speed along either axis is 1000mm/min, but in principle you could ask for higher cutting speeds and if you are cutting along a diagonal, you might achieve them. What is also relevant, maybe, is that it doesn't matter if you have different max speeds along each axis; Mach/LCNC will do the sums needed to make sure you don't exceed either max although this may mean that rapid moves will achieve different speeds over the bed depending on direction.
That all seems pretty straightforward, but it's the difference between G0 and G1 that I'm not quite clear about. G0 takes max speeds for each axis which you have defined for the machine, and will use them for G0 rapid moves and may even achieve speeds over the bed above the max for an axis if you happen to move along a diagonal. G1 needs a speed defined (either by setting it once in the gcode and using it as a default or by setting it in each G1 command) and will use this to calculate actual cutting speed whether along an axis or at some angle (or even around an arc), as long as max speed per axis is not exceeded. I think this means that if I stick a G0 move in at the top of my gcode file with a ridiculously fast F setting, then LinuxCNC will always give me the fastest rapids that preset max X and Y settings permit, but I should make sure that the F setting for g1 cuts is the actual cutting speed that I want. I use LinuxCNC, by the way, so maybe there is also a slight difference of interpretation compared to Mach 3.
As far as the original question is concerned, all this means is that you can look at max speed and accel along each axis independently in order to avoid missing steps and other nastiness, and actual speeds over the bed are just an accident of geometry and don't affect design and tuning parameters. If you are missing steps along X, say, during rapid feeds you might choose to reduce accel or max speed on that axis but you don't necessarily have to change Y if that is working fine with its current settings. However, if you get skipping during cuts, then it's a bit more complicated and you probably need to reduce the F cutting speed parameter just to reduce load as you can't tune this by axis.
And my apologies, guys - I was desperately trying to find an excuse for using nested integral signs and the odd greek symbol from the LaTeX library but just couldn't find a way to fit them in...
Last edited by Neale; 16-01-2014 at 10:59 AM. Reason: Corrected typo - thanks, Jonathan!
The Following User Says Thank You to Neale For This Useful Post:
Otherwise, nicely summarised.
It's just occurred to me that you could actually do something useful with that formula - potentially surface your bed faster by using a raster pass set to that angle.
Ooh, an excuse for some calculus! That'll get 'em rolling in the aisles...
Thanks for pointing out typo, Jonathan - correction made.
On the F setting and G0, though - my comment was based on my experience with LinuxCNC, and I wonder if I have misremembered or LCNC works a little differently to Mach 3 (which seems from casual observation on this forum to be much more popular). If I type G0 commands into LCNC to move the machine "manually", my recollection is that it bitches if it has not seen a previous F setting in a G0 context. I tend to have to type something like "G0 X100 Y100 F1200". Once I've done that, I don't need the F parameter for subsequent G0 commands. In other words, it doesn't seem to default to the max machine speeds. The way you describe it makes much more sense and I wish it worked like that on my system but it doesn't seem to. I'll have to experiment - I might have missed something subtle.
According to the definition here, it shouldn't be a problem:
Also notice that they mention what we just discussed - 'The maximum rapid traverse rate can be higher than the individual axes MAX_VELOCITY setting during a coordinated move.'
By kemo_2002 in forum Workshop & EquipmentReplies: 7Last Post: 12-04-2014, 09:16 PM
By Lee Roberts in forum Computer HardwareReplies: 1Last Post: 13-09-2013, 11:11 AM
By HiltonSteve in forum Gantry/Router Machines & BuildingReplies: 81Last Post: 10-06-2012, 01:33 PM
By Jonathan in forum General DiscussionReplies: 1Last Post: 08-06-2012, 08:15 AM
By M250cnc in forum General ElectronicsReplies: 4Last Post: 25-11-2010, 01:06 PM