500,347 active members
6,189 visitors online

# Thread: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cases)

1. ## Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cases)

Machines known for this problem:
Okuma LB3000 EX II-MY C950
Okuma LB3000 EX II M C1000 with SMW SLUX-2 snug on steady rest
Okuma Genos M560R-V with Tsudakoma RNA 200R (A-axis rotary table)
Okuma Genos M560-V-E with Tsudakoma RNA 200R (A-axis rotary table)

As the manual describes: When interpolating one or more linear axis simultaneously with a rotary axis be it C or A for lathe or machining center , the feedrate must be input in the unit of degrees/minute. As it turns out, in some radical situations when the angular movement is very small like 0,01 degrees and the linear movement is fairly large like 2 mm (and thus thus the angular feedrate has to be pretty low) the control differ from the above described behaviour , instead it interprets and carries out the input feedrate in a mm/minute fashion so the driving factor to the feedrate is the linear axis velocity and the rotation feedrate follows that motion. In these cases the actual tool feedrate is
magnitude lower than the desired one.

Now I'm pretty sure that this phenomena originates from a mathematical/physical limitation of the machines axis control system/motor encoder division numbers.
And here we are closing on my main problem that may fancy the minds of some of us who like to learn each day.
In an ideal world the proper solution for the problem is Inverse Time Feedrate command.
As it looks like today, there is no chance of getting that function in a short manner of time and i still have some parts that needs to be machined with the above mentioned machines.

After I developed a macro in Edgecam to calculate the proper feedrate for the moves when I use rotary axis it turns out I get beautiful feedrate output, tested it in some ridiculously radical situations when really low angle and large axial movement crated an ultra small feedrate and the output is correct. I also make use of G119 on the lathes so i can input mm/minute feedrate for the circular interpolations and the motion is perfect in circles. but I don't have the G175 command on the machining centers and that makes the output always so grainy
Anyway all thing works fine but I would really need to know what is exactly the threshold of the applicability of the angular feedrate in terms of relation to the simultaneously interpolated linear axes travel distance (wonder why I didn't us this sentence as the title ) so that I could test it in the post processing macro and output mm/min feedrate when needed.

I really Hope that someone have some good Idea on this

2. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

there are some debatable things in your post, but, instead of talking, i suggest you share a simple code & drawing, so to locate and analyze the behaviour that you wish for

let's begin with the lathe / kindly

3. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

In the post to make my self sure in the debug part i made a calculation with the inverse time equation too and it gives the same values not to mention the manual paperform calculations which gave the same values.
I encounter a limitation of machine control and that was clearly demostrated when I issued the same F0,1 feedrate for linear + rotary axias move and only rotary axis move and the cutting time differed by orders of magnitude
like 1 minute for a movement that moved 0,02deg and high linear distance (2-3mm) and 0,2 seconds for the same 0,02 deg move when issued without any linear axis movement with the same 0,1 deg/min feedrate.

Just to prove I'm not talking about the air I put up some pictures of the finished parts.

Attachment 407200Attachment 407202Attachment 407204

And a bit of the code at the problematic situation for the lathes
The Wrap heigt (x choords are in diametric value and the programmed planar feedrate is 180mm/minutes
now anyone can check that the feedrate is calculated correctly.
I did not include the preparatory lines but they are
M110
or
G136
G119

Code:
``` (numbers 1)
G0 X59.92 Z-253.039 C174.732 M16
G0 X58.92 Z-253.039
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
G0 X59.92 Z-249.402
G0 X59.92 Z-245.039 C174.732 M15
G0 X58.92 Z-245.039
G1 X57.12 Z-245.039 F50
G1 X57.12 Z-240.361 C174.731 M16 F0.028  <----
G1 X57.12 Z-241.402 C172.66 M16 F252.4
G0 X59.92 Z-241.402```

4. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

hey, so you are saying something like this :
... dc0.02 dz2 : 1 minute
... dc0.02 : 0.2 seconds
* both F0.1 ( G95 i supose ... )

pls share :
... 1 ) rpm for M axis
... 2 ) cilinder ( material / part ) diameter
... 3 ) tool cutting edge diameter

for engraving operations, 2 & 3 should be pretty close

i will give you a nice code, that you may test, and if it works fine, then i will share more details

how do you determine those times ? kindly

5. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

My main concern is the behaviour of the machine, the code is ok and the feed is ok, I'm working on the problem for two months by now, so please answer the machine related problem, this is not a discussion about the G code, but the axis control system
But still the tool is at 0,4mm radial depth in the material
the stock diameter is 58mm
Tool rotational speed is completely irrelevant since i have already determined the (G95) mm/minute feedrate for the tool in 180mm/minutes
but since I'm a nice guy i can tell you I do it with a tool called SFI Toodle Blue and it is putting out around 40k rpm at 10bar pressure
for the calculation part i used a lot of the supplement from the okuma books

Attachment 407214Attachment 407216Attachment 407218

I calculate the C axis rotation arc lenght: call it C component : Wrapradius * 3,1416.... * 2 * ( angular movement / 360) just for curiosity
i can calculate the spiral lenght : call it CZ component lenght : SQR (((angular distance * 3.1415926535 * wrap radius) /180)^2+ Z distance^2)
The feedtime can be calculated as follows : Feedtime= CZ spiral lenght / planar feedrate distance / velocity = time of the movement
Angular feedrate should be : Angular feedrate = Angular movement / feed time or ( planar feed * Angular movement) / CZ component lenght

they both give the same value and by the way inverse time feedrate for one rotary axis is calculated just as the last formula

6. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

hello ungie please share the feed in G95 ( & times, if possible ) for those 3 movements :

Code:
```    SB = 750 M13       ( please use feed 0.1 mm / revo )
G00 X58 Z2.5 C30

G01 Z 0   C30
Z-2.5 C30.02
Z-2.5 C30.04```
i wish to compare results; i have allready run some tests, and all is ok

if results will be the same, but times will be different, then there is a problem with your machine, more precisely, you may need some optional specs

if results are different, then we will talk futher

you need to be near these numbers :
... feed G95 [ mm / o ]: 0.1 0.1 0.274
... time [ ms ] : 2007 2037 25

kindly

7. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

F180 mm / min ( 1800 * 0.1 )
diameter 58

1 minute for a movement that moved 0,02deg and high linear distance (2-3mm)
dz2.5 dc0.02 : requires 0.833 seconds

0,2 seconds for the same 0,02 deg move when issued without any linear axis movement with the same 0,1 deg/min feedrate
dz0 dc0.02 : requires 0.003 seconds

little ratios check : 60 / 0.2 vs 833 / 3 ; 300 vs 277 .... hmm ratios are amost ok, maybe there is a proportional problem ? i don't know / kindly

8. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

I can not fizzle with the machine for now but i can include a part that contains the debug information

I am aware that i can roughen up the toolpath a bit an get rid of the micro angles but still time to time we encounter 1-2 moves somewhere in the program where the angle is really small compared to the linear component and thus for the post-processor is not capable of outputting code wich not needs to be checked.... I am only using this precision of Angle output because it does a good representation of the situation

I have no intent to upload the full macro i have wrote, but i include the calculation part so that can be analysed
Just noticed now that i havent rounded down the input values to 3 decimals so there is a slight offset in the feeds but that will be corrected soon
Programmed linear feedrate 180mm/min

all other data is there

Code:
``` (numbers 1)
*          X incr:0.0//  Z incr:131.317 //  C incr:5.304 //  C ROT DIR: 1
G0 X59.92 Z-253.039 C174.732 M16

*          X incr:1//  Z incr:0.0//  C incr:0.0//  C ROT DIR: -1
G0 X58.92 Z-253.039

*          X incr:1.8//  Z incr:0.0//  C incr:0.0//  C ROT DIR: -1
G1 X57.12 Z-253.039 F50

*          X incr:0.0//  Z incr:-4.678//  C incr:0.001//  C ROT DIR: -1
*          C angle:        0.001 // Wrap radi: 28.96// C arc lenght: 0.0
*          CZ arc lenght:  4.678// Feed Time: 0.026//  Ang Feed: 0.028
G1 X57.12 Z-248.361 C174.731 M16 F0.028

*          X incr:0.0//  Z incr:1.041//  C incr:2.071//  C ROT DIR: -1
*          C angle:        2.071 // Wrap radi: 28.96// C arc lenght: 1.047
*          CZ arc lenght:  1.476// Feed Time: 0.008//  Ang Feed: 252.4
G1 X57.12 Z-249.402 C172.66 M16 F252.4

*          X incr:-2.8//  Z incr:0.0//  C incr:0.0//  C ROT DIR: -1
G0 X59.92 Z-249.402

*          X incr:0.0//  Z incr:-4.363//  C incr:-2.072//  C ROT DIR: -1
G0 X59.92 Z-245.039 C174.732 M15

*          X incr:1//  Z incr:0.0//  C incr:0.0//  C ROT DIR: 1
G0 X58.92 Z-245.039

*          X incr:1.8//  Z incr:0.0//  C incr:0.0//  C ROT DIR: 1
G1 X57.12 Z-245.039 F50

*          X incr:0.0//  Z incr:-4.678//  C incr:0.001//  C ROT DIR: 1
*          C angle:        0.001 // Wrap radi: 28.96// C arc lenght: 0.0
*          CZ arc lenght:  4.678// Feed Time: 0.026//  Ang Feed: 0.028
G1 X57.12 Z-240.361 C174.731 M16 F0.028

*          X incr:0.0//  Z incr:1.041//  C incr:2.071//  C ROT DIR: -1
*          C angle:        2.071 // Wrap radi: 28.96// C arc lenght: 1.047
*          CZ arc lenght:  1.476// Feed Time: 0.008//  Ang Feed: 252.4
G1 X57.12 Z-241.402 C172.66 M16 F252.4

*          X incr:-2.8//  Z incr:0.0//  C incr:0.0//  C ROT DIR: -1
G0 X59.92 Z-241.402```

Macro for calculation

Code:
```#INCX              ;   *incremental X value*
#INCZ              ;   *incremental Z value*
#INCC              ;   *incremental C value*
#ZCOMP           ;   *Z component*
#CCOMP           ;   *C unrolled lenght*
#ANGFEED        ;   *Angular feedrate*
#FEED               ;    *programmed linear fedrate
#FEEDTEMP       ;   *Temp feed mm/min*
#FEEDTIME        ;   *Time of actual cutting move in minutes*
#CZCOMP          ;   *CZ component lenght*

#CZCOMP=SQR(#CZCOMP)

#FEEDTIME=#CZCOMP/#FEED
#ANGFEED=(#FEED*#INCC)/#CZCOMP    ; OR IT CAN BE  #ANGFEED=#INCC/#FEEDTIME```

9. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

hello again

i can roughen up the toolpath a bit an get rid of the micro angles
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

Just noticed now that i havent rounded down the input values to 3 decimals so there is a slight offset in the feeds but that will be corrected soon
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

I have no intent to upload the full macro i have wrote
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 include the calculation part so that can be analysed
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

As the manual describes: When interpolating one or more linear axis simultaneously with a rotary axis be it C or A for lathe or machining center , the feedrate must be input in the unit of degrees/minute
you got tricked

In an ideal world the proper solution for the problem is Inverse Time Feedrate command
... and you tried a way arround it, so you added another variable to something that was not certain

I also make use of G119 on the lathes so i can input mm/minute feedrate for the circular interpolations and the motion is perfect in circle
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

My main concern is the behaviour of the machine, the code is ok and the feed is ok
at post5, you shared those examples, from the manuals ... they are not explained extraodinary well, and maybe something happened

Tool rotational speed is completely irrelevant since i have already determined the (G95) mm/minute feedrate
G94 is mm/min

but since I'm a nice guy
do you have a mustache ?

Tool rotational speed is completely irrelevant since i have already determined the (G95) mm/minute feedrate for the tool in 180mm/minutes
but since I'm a nice guy i can tell you I do it with a tool called SFI Toodle Blue and it is putting out around 40k rpm at 10bar pressure
for the calculation part i used a lot of the supplement from the okuma books
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

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

I'm so happy that i found You but since You are not pushing the issue forward, pleas leave this post before i delete it.

If i would use inverse time feed than a single line with 200 feedrate would complete in 200 seconds and that is not true . So i dont know how on earth can You belive that i use that, not to mention that the control is not equipped with that option... As an owner please let me know what i have and what not. The precision thing is another point when you highlighted that you dont know what you are talking yourself into: the macro input precision was set to 8 decimals ie it happened some cases that an actually 0.001 angular movement outputted to gcode got a feedrate which was calculated for 0.0007 angle cus the macro input values were not rounded down to 3 decimals. Think about it, if i were way off with my feeds how that would affect a tiny VHM 40 deg conical engraving mill..... It would have broke the tool all the time and that was not the case.. please dont reply anymore because You dont want to help, in my opinion you just want to be active on the site but dont do it on my posts
Oh and almost forgot: my edgecam postprocessor is set up by me and it has been tested with simple parts it is capable of outputting code for the following planes, motions
G17 Y axis milling, drilling with cycles
G17 rotary milling with angular coordinates and with descartes type coordinate transformation
G18 turning with simple moves, did not bothered with cycles
G19 Y axis milling, drilling with cycles and helical milling with cuttercompensation as well
G119 cylinder side machinig with C CZ moves

I live with these controllers for years by now i face a limit of the controller and you try to lead me into self questioning... Amswér the original qiestion! Find á máchine test the problem understand that i am right in my first proposal, then we can discuss my problem. Dont maje me upload a video to prove You wrong

11. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

hei, don't rush into such conclusions

If i would use inverse time feed than a single line with 200 feedrate would complete in 200 seconds and that is not true . So i dont know how on earth can You belive that i use that
in 1st post, you said that "In an ideal world the proper solution for the problem is Inverse Time Feedrate command.", so i suposed you use it, or you intend to use it

not to mention that the control is not equipped with that option
do you need that option ?

The precision thing is another point when you highlighted that you dont know what you are talking yourself into: the macro input precision was set to 8 decimals ie it happened some cases that an actually 0.001 angular movement outputted to gcode got a feedrate which was calculated for 0.0007 angle cus the macro input values were not rounded down to 3 decimals
that was a general observation, i was not refering to the fact that it hapens to you / your softare whatever ...

Think about it, if i were way off with my feeds
i really believe that you are off with you feeds :
... the problem you described in post 3 ( underlined text ) i allready tested it, and it works here without a problem
... i checked your code from post 8, and i have obtained different feeds

Think about it, if i were way off with my feeds how that would affect a tiny VHM 40 deg conical engraving mill
you are generating lower feeds, not higher feeds, so the tool does not break, but gets dulled doc is small, so this effect is not visible

You dont want to help
i allready spent hours checking your issue, and runing trials on real machine

it is hard to convince you, because you still believe that your code is ok, and there is a problem with the machine

onestly, i did not started to talk, i only replied to your posts, because i wait for the moment when you realize that the machine is ok, or you are missing a spec; however, i don't believe that your machine is missing the spec, because your calculations are wrong; i have checked them, so, as long as your values are not ok, i assume that the spec is there

in attached archive, you can see the files/programs that i have created to check you issue

also, in my previous reply, you have a numerical example, showing how to calculate such feeds / kindly

12. ## Re: Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cas

let's reload : this is how i calculate feed G94, for a given dz dc X f_G95 n_rpm : sqrt ( ( ( 360 * dz ) ^ 2 + ( 500 * dc ) ^ 2 ) / ( ( 360 * dz ) ^ 2 + ( X * dc * pi ) ^ 2 ) ) * f * n

if you wish, please compare the results of that formula, with your method

i have allready done this, when i checked your code, and i have seen a difference

i have a nice code, and it works for small angles; you keep talking about your method being correct, and you are blaming the machine

i started such calculations years ago,
i also had problems with angles a while ago, but i fixed them

i have had delivered many parts that required such things, and for your code, i have used a soubroutine which is 3 iterations older then my actual code

thus i tested your code with a soubroutine that i no longer use / kindly

ps : pls stop quoting my entire posts / makes me go crazy ...

Page 1 of 2 12