G93 problem with speed
I have a problem suing G93 inverse time feed.
The issue is that it seem not seem to work when only A axis is to move.
When I try (in both cases starts A 0 and X0)
G1 A360 f1
and
G1 A360 f0,1
A axis turns with the same speed. I thinks it is the max speed as set in config
But if A moves are companied by any linear move A axis turns with appropriate speed.
So
G1 X0,1 A360 f1
and
G1 X0,1 A360 F0,1
both are executed as expected
Why it is so G93 does not work for A axis movement alone?
Cris.
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 17369
- Thank you received: 5789
Thank you.
Please Log in or Create an account to join the conversation.
So my findings are:
1) when G93 is used and if there is linear move to be done in the same time as rotation there is minimum linear feed that controller uses and this is 0,1 mm/min.
If code requires smaller linear feed it will not controller will not do it and will go with minimum linear feed rate 0,1. This is why in some cases G93 does not produce effect as expected
2) If G94 is sued and there are linear and rotation moves combined in the line of code feed is based on linear feed, so move is executed in the time linear moves would need to do the move with given federate.
If only rotation is present in the line of code than federate value is executed in angular units.
3) to solve this problem I am using G94 instead of G93 but with F specific for each line of code involving rotation of 4-th axis.
To get F value for given feed rate very simple calculations are required.
This strategy is error proof as if F is specified for G94 it can have any value, in particular it can be smaller than a minimum F value controller uses for G93. So for G 94 F can be as small as 0,05 mm/min (this I have tested, but I suppose there is no lower limit for this value).
So in a sense it turns out that G93 is not safe to use and using G94 instead requires exactly the same calculations but is error proof.
Cris.
Please Log in or Create an account to join the conversation.
github.com/LinuxCNC/linuxcnc/blob/master...terp_inverse.cc#L124
Though presumably you could split a long move that was meant to take 20 minutes into two 10 minute moves.
That said, 10 minutes seems like a long time to be doing one move.
Are you making marble columns or something?
Please Log in or Create an account to join the conversation.
I am happy to consider changing it. I wonder how small is small enough? Maybe 0.0007 ? (no single cuts longer than a day)
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 17369
- Thank you received: 5789
LOL, that ought to be enough!Maybe 0.0007 ? (no single cuts longer than a day)
Please Log in or Create an account to join the conversation.
But feed limit is not about how long does a move take but what is the speed of the move.
So there can be a move that takes more than a day and is done with significant speed but there also can be a move that takes 30 seconds and requires to be done with feed rate of 0,01
So in fact there should be no lower limit for the G93 feed rate, which is NOT the same as time required to complete the move.
Feed rate limit for G93 is in fact not limit for the time this move is to last. But it is a limit for the Speed of the linear move that can be used.
So for example:
G91 (incremental)
G93 G1 X1 F0,10
(this command requires so move is completed in 10 min. and travel distance is 1mm, so required linear speed is 0,1 mm/min. This move is executed fine, as it requires to be executed with minimum allowable linear speed coded for G93)
G93 G1 X1 F0,05
(this command requires so move is completed in 20 min. and travel distance is 1mm, so required linear speed is 0,05 mm/min. This move is executed with linear speed of 0,1 so twice as fast as required, as 0,1 is the coded limit for G93 moves, and therefore this move takes half of the time it should, and actual feed/rev is also twice as we would like.)
G94 G1 X1 F0,05
(this move is coded with G94 and is exactly the same move as above, requires so move is executed with linear speed of 1/20mm/min, travel distance is 1mm so move should take 20 min. This move is executed with no problems)
So in case of G93 problem is not how long does a move take, and splitting long moves in two shorter once does not solve any problem, and actual problem is that thee is lower limit for SPEED of the move, and not the time.
As far as mathematical conditions are in question lower speed of the move needs to be positive and not zero. As long as this is the case there are no issues to be expected.
Cris.
Please Log in or Create an account to join the conversation.
Here I attach mu sub procedure I use, that basically does the same as piece of code form your link, but in the end it executes the result as a G94 move.
This works 100% correct in (accepting some simplifications I made for my convenience).
As you can see (please refer attached file for full code) there is no lower limit for feed in G94.
o11 if [#<VelLinear> GT 0]
/g4 p2 (debug purpose)
g94 f[#<VelLinear>] g1 x[#<Xc2>] y[#<Yc2>] Z[#<Zc2>] A[#<Ac2>]
So having this condition in linuxcnc is not required at all.
rate = std::max(0.1, (length * block->f_number));
Or actually this condition is required to prevent setting negative federate, so if 0 is used instead of 0,1 this will work fine.
in case of en error of some sort worst what will happen is federate will be set to 0.
Cris.
Please Log in or Create an account to join the conversation.
So in fact there should be no lower limit for the G93 feed rate, which is NOT the same as time required to complete the move.
No, that is exactly what G93 means. G93 F1 means the move takes 1 minute. G93 F0.1 means that it takes 10 minutes. That is why it is called inverse time mode, you tell the system how long the move should take, not how fast it should be
(and "inverse" because you tell it that in a stupid way, but it's traditional)
So in case of G93 problem is not how long does a move take, and splitting long moves in two shorter once does not solve any problem,
Try it. It will. (but only for G93)
Which isn't to say that I disagree that the limit is spurious and should be removed or reduced.
and actual problem is that thee is lower limit for SPEED of the move, and not the time.
As far as mathematical conditions are in question lower speed of the move needs to be positive and not zero. As long as this is the case there are no issues to be expected..
My assumption is that it is an attempt to avoid a potential divide-by-zero somewhere. Programmers are (rightly) paranoid about that.
Please Log in or Create an account to join the conversation.
kmeld wrote: So in fact there should be no lower limit for the G93 feed rate, which is NOT the same as time required to complete the move.
No, that is exactly what G93 means. G93 F1 means the move takes 1 minute. G93 F0.1 means that it takes 10 minutes. That is why it is called inverse time mode, you tell the system how long the move should take, not how fast it should be
(and "inverse" because you tell it that in a stupid way, but it's traditional)
Clearly we have a misunderstanding here.
I am not saying F word in G93 defines federate, of course it defines time.
When I write about the feed rate I mean actual speed machine moves with.
So of course G93 F0,1 means that the move should be completed in 10 minutes. but what will be the actual feed rate of the move is dependent directly on the length of the move. So it will be 10mm/10 min if move is 10mm long and it will be 100mm/10min if move is 100mm long.
In the part of my previous post I was trying to point out that problem I am facing cannot be solved by splitting moves in two moves as this does not change feed rate (speed) of the move, and this (speed) is what is actually limited by hard coded 0,1.
So if we have a G93 move that requires machine to go with speed (actual physical feed rate) less than 0,1 mm/min it will not work, as it will go with 0,1 (as hard coded minimum). And it is not relevant if this move should take 1 or 10 minute.
As for the minimum value in the condition:
rate = std::max(0.1, (length * block->f_number));
in the end this function sets:
enqueue_SET_FEED_RATE(rate);
settings->feed_rate = rate;
And actually Linuxcnc is already error proof for trying to go with 0 feed rate.
and even if
rate=0
"cannot go with 0 feedrate"
(few times I have encountered that, as coding most by typing)
In any case, I think we have found the root of the issue here.
I wonder if there is a way to change that condition in question?
Cris.
Please Log in or Create an account to join the conversation.