# G93 problem with speed

31 Dec 2020 12:31 #193640 by kmeld
G93 problem with speed was created by kmeld
Hi,
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.

09 Jan 2021 15:56 #194597
Replied by tommylight on topic G93 problem with speed
Pretty sure some axis in some cases do not comply to feeds, but i have no idea how and why and when or under what circumstances, so i'll leave that to more experienced members.
Thank you.

10 Jan 2021 09:29 #194696 by kmeld
Replied by kmeld on topic G93 problem with speed
So I have found something in the matter, and have gone around the problem and have a stable solution in all cases.

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.
The following user(s) said Thank You: newbynobi, tommylight

10 Jan 2021 23:57 #194819 by andypugh
Replied by andypugh on topic G93 problem with speed
There definitely does appear to be a hard-coded limit of 0.1
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?

11 Jan 2021 00:08 #194821 by andypugh
Replied by andypugh on topic G93 problem with speed
I have asked the developers if anyone knows why there is this limit. But it has been like that since 2005 so I doubt that anyone remembers.

I am happy to consider changing it. I wonder how small is small enough? Maybe 0.0007 ? (no single cuts longer than a day)
The following user(s) said Thank You: tommylight

11 Jan 2021 00:33 #194828
Replied by tommylight on topic G93 problem with speed

Maybe 0.0007 ? (no single cuts longer than a day)

LOL, that ought to be enough!

11 Jan 2021 08:33 - 11 Jan 2021 08:39 #194858 by kmeld
Replied by kmeld on topic G93 problem with speed
wow, what a feedback.

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.
Last edit: 11 Jan 2021 08:39 by kmeld.

11 Jan 2021 08:53 - 11 Jan 2021 08:56 #194861 by kmeld
Replied by kmeld on topic G93 problem with speed
As for explanation about splitting moves it is explained in the post above.

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.
##### Attachments:
Last edit: 11 Jan 2021 08:56 by kmeld.

11 Jan 2021 13:53 - 11 Jan 2021 13:53 #194904 by andypugh
Replied by andypugh on topic G93 problem with speed

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.
Last edit: 11 Jan 2021 13:53 by andypugh.

11 Jan 2021 18:19 #194931 by kmeld
Replied by kmeld on topic G93 problem with speed

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`
There should be no problem as you will get an orderly error message saying:
"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.