584,879 active members*
5,329 visitors online*
Register for free
Login
IndustryArena Forum > MetalWorking Machines > Okuma > Simultaneous Rotary and Linear Axis Feedrate (deg/min at least in most of the cases)
Results 1 to 13 of 13
  1. #1
    Join Date
    Oct 2010
    Posts
    51

    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. #2
    Join Date
    Jun 2015
    Posts
    4131

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

    hi, i believe i can help you

    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
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  3. #3
    Join Date
    Oct 2010
    Posts
    51

    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. #4
    Join Date
    Jun 2015
    Posts
    4131

    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
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  5. #5
    Join Date
    Oct 2010
    Posts
    51

    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. #6
    Join Date
    Jun 2015
    Posts
    4131

    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
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  7. #7
    Join Date
    Jun 2015
    Posts
    4131

    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
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  8. #8
    Join Date
    Oct 2010
    Posts
    51

    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*
    #WRRADIUS     ;   *Wrap radius*
    #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*
    
     #CCOMP=#WRRADIUS*3.1415926535*2*(#INCC/360)
     #CZCOMP=(((#INCC*3.1415926535*#WRRADIUS)/180)^2+#INCZ^2)
     #CZCOMP=SQR(#CZCOMP)
    
     #FEEDTIME=#CZCOMP/#FEED  
     #ANGFEED=(#FEED*#INCC)/#CZCOMP    ; OR IT CAN BE  #ANGFEED=#INCC/#FEEDTIME

  9. #9
    Join Date
    Jun 2015
    Posts
    4131

    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

    please answer the machine related problem
    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
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  10. #10
    Join Date
    Oct 2010
    Posts
    51
    Quote Originally Posted by deadlykitten View Post
    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. #11
    Join Date
    Jun 2015
    Posts
    4131

    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
    Attached Files Attached Files
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  12. #12
    Join Date
    Jun 2015
    Posts
    4131

    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 ...
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

  13. #13
    Join Date
    Jun 2015
    Posts
    4131

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

    hello again

    ... i took a portion of your code; image 00
    ... i recreated it in igf, so to output 180mm/min, X57.12, and same CZ increments : C0.001 Z4.678 & C2.071 Z1.041; image 01
    ... igf generated the program shown in image 02
    ... in image 03, is a tiny centralizer, which shows feeds from your program, vs igf output, vs results from my formulas

    i hope this will trigger a light / kindly
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg

Similar Threads

  1. Replies: 1
    Last Post: 07-09-2018, 05:47 AM
  2. Replies: 2
    Last Post: 02-07-2016, 06:08 PM
  3. Replies: 2
    Last Post: 11-11-2015, 01:55 PM
  4. linear motion feedrate problems
    By tigran in forum Mach Mill
    Replies: 15
    Last Post: 07-09-2009, 09:06 PM
  5. Help! Rotary axis feedrate
    By Matt@RFR in forum Mastercam
    Replies: 3
    Last Post: 12-25-2007, 01:38 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •