[Dodge68]

for turning a radius on a part what does the I & K stand for example
G1Z0
X1.75
G3X2.0 Z-.125I ? K ?

[CadCamSam]

It is the distance to the center of the arc.
X Y Z
I J K

See how they go in order?

[Fancuku]

for turning a radius on a part what does the I & K stand for example
G1Z0
X1.75
G3X2.0 Z-.125I ? K ?

I would use R instead.
G3 X2.0 Z-.125 R0.125

[I-y-y]

hi
could you please help me about allen bradley characterization axcfil

[kruel037]

Hi guys,

I am new here as well as in lathe working. And I need an advice if you can help .

My machine(jnc 25 star) is old but in my opinion it is in good condition.

And here is my question , what should I do to have a good for example M05 drill threed?
Do I need tapmatic? Should I use G84 or some better solution...?

Thanks!

[Jcowles1986]

Hi guys,

I am new here as well as in lathe working. And I need an advice if you can help .

My machine(jnc 25 star) is old but in my opinion it is in good condition.

And here is my question , what should I do to have a good for example M05 drill threed?
Do I need tapmatic? Should I use G84 or some better solution...?

Thanks!

Depending on how old the star is you might have to do a a G1 with tap feerate in and then stop spindle,reverse spindle and G1 feed out with tap feedrate.
Ive seen it done on Citizens cincom F12.

[__Britt]

I would use R instead.

Depending on the control in question; and the exact geometry involved, the R word can fail to resolve properly. The I, J, and K words are more numerically stable... so if you get odd behavior, try switching to direct offsets.

[deadlykitten]

Depending on the control in question; and the exact geometry involved ....

hi, that is relative to accuracy of the software that generated the program, the way it rounds up numbers, etc; in such a case, errors should be the same, regardless of g-code syntax ( R vs ijk ); depends on post algorithm

to deal with less accurate coordinates, some cnc controllers may use a parameter to tolerate the in-position of g02/g03s

to achieve higher accuracy toolpath, one may need to check the accuracy of the software, use zero-tolerance inside the machine parameter, and adjust specs accordingly / kindly

[angelw]

hi, that is relative to accuracy of the software that generated the program, the way it rounds up numbers, etc; in such a case, errors should be the same, regardless of g-code syntax ( R vs ijk ); depends on post algorithm

to deal with less accurate coordinates, some cnc controllers may use a parameter to tolerate the in-position of g02/g03s

to achieve higher accuracy toolpath, one may need to check the accuracy of the software, use zero-tolerance inside the machine parameter, and adjust specs accordingly / kindly

It has nought to do with what you have suggested. Typical Motion Control Software, that which generates the motion trajectory, typically uses an Arc Centre, Arc Radius, and the included Angle of the Arc. Also typical, is the numerical precision used in calculations in even the most lacking program generation Software, and is far more accurate than the Least Programmable Increment that is overwhelmingly used with CNC Machines of 0.001mm and 0.0001".

When a program is generated using IJK in Circular Moves, the centre of the Arc is calculated from the Start Point of the Arc using CAM Software, or manually using a Calculator that is working at a far more accurate level than the Least Programmable Increment of the Machine Control and the values Rounded to the accuracy of the control. Even if the program is Rounded to an accuracy greater than that of the Least Programmable Increment of the Machine Control, the control will truncate the value to its Least Programmable Increment. Accordingly, the centre of the Arc translated to the Control by IJK is as accurate as the control can resolve.

When the Arc Move in a program use the R Format, the Start and End Point of the Arc are calculated using high precision calculations and are Rounded to the Least Programmable Increment of the Control. The R Format doesn't specify the centre of the Arc directly, as does the IJK Format, and as the Motion Control requires the Arc Centre, the Control must calculate the Centre using the Start/End coordinates and the Radius supplied. However, rather than use data that has a higher precision than its Least Programmable Increment, as does the CAM Software or Calculator, the Control uses data that has already been Rounded to Its Least Programmable Increment. Accordingly, there will be cases where the Arc Centre calculated by the control when R Format is used in the supplied program will be less accurate than when the Arc Centre is translated to the control using IJK Format in the supplied program.

[deadlykitten]

hi, considering that code is ok, for both R and IJK variant, the difference between them may shift the center position with 1um, and this is not such a big deal; even diff is generally > 1um

about how code is generated, this is a different story:
... worst case scenario : a G91 toolpath made of many arches, that adds truncation errors, that may lead to shifting the end-point of the toolpath, or even making it impossible for the controller to reach then end point of the tooltapth; here is where, the rad comp parameter of okuma's kick in, so to deal with 'nasty' codes
... best case scenario : outputing coordinates with more digits then the controller can display, on a controller that is not truncating

Even if the program is Rounded to an accuracy greater than that of the Least Programmable Increment of the Machine Control, the control will truncate the value to its Least Programmable Increment.

truncation does not always happen inside the controller; it may still round up and do the math at a higher level then the axis positioning acuracy; okuma osp was truncating until a while ago, at least for g91 mode, but a recent update just fixed that

however, there is still an ocasional problem with rounding, but there is a low chance to affect the g02/g03s

It has nought to do with what you have suggested

it's always a pleasure to see your comments; i have seen that your skills, about spindle phase & z axis syncronization, when threading, have increased, and the 1st time when i told you about the "desincronization" you have had hardly believed that is true

give it time angel; so far, you did not teached me anything new / kindly

[angelw]

hi, considering that code is ok, for both R and IJK variant, the difference between them may shift the center position with 1um, and this is not such a big deal; even diff is generally > 1um

about how code is generated, this is a different story:
... worst case scenario : a G91 toolpath made of many arches, that adds truncation errors, that may lead to shifting the end-point of the toolpath, or even making it impossible for the controller to reach then end point of the tooltapth; here is where, the rad comp parameter of okuma's kick in, so to deal with 'nasty' codes
... best case scenario : outputing coordinates with more digits then the controller can display, on a controller that is not truncating



truncation does not always happen inside the controller; it may still round up and do the math at a higher level then the axis positioning acuracy; okuma osp was truncating until a while ago, at least for g91 mode, but a recent update just fixed that

however, there is still an ocasional problem with rounding, but there is a low chance to affect the g02/g03s



it's always a pleasure to see your comments; i have seen that your skills, about spindle phase & z axis syncronization, when threading, have increased, and the 1st time when i told you about the "desincronization" you have had hardly believed that is true

give it time angel; so far, you did not teached me anything new / kindly

You teach the uninformed all that you know and they still know nothing. By expressing your ideas simply exhibits what little you know about CNC machining and programming in general.

You don't get it that the Control is working with the data supplied by a program that has been created externally and already Rounded to the Least Programmable Increment of the Control. Posting a program that has been Rounded to an accuracy greater than the Least Programmable Increment of the control does nothing other than unnecessarily consume memory. Irrespective of the accuracy level the Control may be able to perform calculations internally, its limited by the accuracy of the data supplied.