G93 problem with speed

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.

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.

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.

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.
So having this condition in linuxcnc is not required at all.
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.

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:
in the end this function sets:
And actually Linuxcnc is already error proof for trying to go with 0 feed rate.
and even ifThere 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.