hello again :)
all feeds should be calculated just fine, regardless of toolpath resolution
in other words, you should consider changing toolpath resolution only to achieve a part with smoother or rougher finish, or to gain some time, or to eliminate some local vibrations, etc; in each case, whatever the toolpath, the code generator should not hit a wall :)
okuma can handle more than 3 decimals, up to 8 or 9 ?! far as i remember, in G91, only 3 decimals are taken into consideration
problem is not the number of decimals, but how the code generator is dealing with numbers, and how it is outputing numbers; in short, it is possible that a wrong code generator outputs many decimals, but it is rounding / truncating / aproximating values during calculations :) this may be an issue with complex tasks
for such tasks, analyzing someone else's soubroutine may be time consuming
at this moment, it should be enough to compare the results generated by both soubroutines
however, for this to work, it means that both soubroutines are outputing same kind of data
for CZ sincronized movements, output kind can be :
... G95 or G94 or G94 Hi-Cut Pro
... customized even more :
...... you seem to be using inverse time feed
...... i may use an unified formula, or simplified feeds, that allows changing feeds only by editing a parameter inside the code, instead of regenerating it at a pc ( it is much faster when it comes to trials, adjustments, etc )
also, input kind can be done in several ways
this is why, in post6, i have written a simple code, that maybe you will find some time to test
that code contains 3 kind of movements : z cz c
also, those coordinates are close to the numbers you specified in post3 :)
it is easier to compare a simple / short code, instead of digging inside a longer one
i looked over it :
... there are 6 feed movements : 2 groups of 3
... groups are simetrical, movements are mirrored, etc, so i considered only 1st group :
Code:
G1 X57.12 Z-253.039 F50
G1 X57.12 Z-248.361 C174.731 M16 F0.028
G1 X57.12 Z-249.402 C172.66 M16 F252.4
... 1st movement is only among X axis, so screw it :)
... 2nd & 3rd are ZC, with feeds 0.028 and 252.4
... if you wish for 180mm/min and diameter 58, those feeds should be 180 and 372
you are miles away :)
please take a look at this example, for " G1 X57.12 Z-249.402 C172.66 M16 F252.4 ", where dz1.041 and dc2.071 :
sqrt ( ( ( 360 * dz ) ^ 2 + ( 500 * dc ) ^ 2 ) / ( ( 360 * dz ) ^ 2 + ( X * dc * pi ) ^ 2 ) ) * f * n
sqrt ( ( ( 360 * dz ) ^ 2 + ( 500 * dc ) ^ 2 ) / ( ( 360 * dz ) ^ 2 + ( 58 * dc * 3.14 ) ^ 2 ) ) * 180
sqrt ( ( ( 360 * 1.041 ) ^ 2 + ( 500 * 2.071 ) ^ 2 ) / ( ( 360 * 1.041 ) ^ 2 + ( 58 * 2.071 * 3.14 ) ^ 2 ) ) * 180
sqrt ( ( 374.76 ^ 2 + 1035.5 ^ 2 ) / ( 374.76 ^ 2 + 377.171 ^ 2 ) ) * 180
sqrt ( ( 140445.0576 + 1072260.25 ) / ( 140445.0576 + 142257.963241 ) ) * 180
sqrt ( 1212705 / 282703 ) * 180 = circa 372
i can help you with all these formulas, cnc soubroutines, help with cam integration, etc
you got tricked :)
... and you tried a way arround it, so you added another variable to something that was not certain :)
even if the motion is reproduced as expected, this does not mean that desired speed is reached
when there is a big difference between real & expected speed, like you have seen, then you start believe that there is something wrong going on
after you fix those CZ sync movements, you may start testing G119
at post5, you shared those examples, from the manuals ... they are not explained extraodinary well, and maybe something happened
G94 is mm/min
do you have a mustache ?
when using attachements, you may use an interlock, or, if not available, simply spin M axis, without conecting it to the toolholder
however, if 180 is output by coolant driven attachement, and not by the controller ( M axis ), this may lead to mistakes :)
there are some things with the machine, but in this case, is all ok
what i don't like is that, during CZ movements, the displayed feed value is <> programed value, and this makes it hard to debug such codes; even when code is ok, is hard to check if it is really ok
in other words, such codes can not be checked in the "classical manner" / kindly :)
