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.

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)

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.

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 if 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.

kmeld wrote: Clearly we have a misunderstanding here.

I think that the explanation for this misunderstanding is that I am an idiot.

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.

Yes, looking at the code properly, the output of the max() function is the final feedrate, not the F-number.

There is a fix on the way: github.com/robEllenberg/linuxcnc-mirror/...93-minimum-feed-rate

I am running rather old version of linuxcnc because I am running an old computer.

I have linuxcnc 2.5.0 on Ubuntu. And tried live CD with new system but it did not work.

Will I be able to somehow install new linuxcnc on my system?

Cris