for turning a radius on a part what does the I & K stand for example
G1Z0
X1.75
G3X2.0 Z-.125I ? K ?
for turning a radius on a part what does the I & K stand for example
G1Z0
X1.75
G3X2.0 Z-.125I ? K ?
It is the distance to the center of the arc.
X Y Z
I J K
See how they go in order?
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!
hi
could you please help me about allen bradley characterization axcfil
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.I would use R instead.
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 algorithmDepending on the control in question; and the exact geometry involved ....
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
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg
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.
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 thatEven 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.
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 trueIt has nought to do with what you have suggested
give it time angel; so far, you did not teached me anything new / kindly
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg
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.
angelw :cheers:
hello again, considering that code is ok, on a 3digits machine, when the control needs to calculate the center, from an R syntax, then the center may be shifted, thus there is a probabiblityIrrespective of the accuracy level the Control may be able to perform calculations internally, its limited by the accuracy of the data supplied.
by probabiblity, i mean that there are cases when the center will be detected with:
... full accuracy, like for quadrant arches ( that start or end at 0 90 180 270* )
... less accuracy, like <=1um for each axis, and that is really low, <diff, etc, so nothing to worry about
please, don't be sure about what 'i don't get' / kindlyYou don't get it that
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg
hello again, in both cases, the result may be affected by an error :
... r syntax : center may be shifted
... ijk syntax : r may be shifted
* even so, effects happens at a scale that is too low, to matter
considering that code is generated ok, and the controller can run both ijk and r, did someone actually hit into a case where 'ijk' was better then 'r', or viceversa ? and if i may, what was exactly the issue ? if you wish to share the code, i will test it for you / kindly
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg
A 360deg circular move can't be programmed in one Block using R Format. In every case where I've seen a full circle programmed using R Format, the user has programmed two Command Blocks, each dealing with 180degs of the full circle; logical on the surface, but not so. Being able to programming the circle in one Block is the first plus for IJK Format in my book.
If there is an error, caused by rounding, minuscule as it may be, when the Control calculates the centre of the arc and shifts the arc centre, there will be a doubling of the error as the shift of the centres will be in opposite directions in each of the 180deg arcs, but it seems that theoretical accuracy matters little to you.
hi / yes, that is true, but a full circle is a particular case, and also R<0 may deliver arches > 180*A 360deg circular move can't be programmed in one Block using R Format.
aaa, do you have a programing book ? i don't know, maybe you do ... if you would have one, i would read itmy book
i use code as accurate as it could be, folowing error is never 0, there is backlash, and most dimensions have a tolerance >1umtheoretical accuracy matters little to you
even when folowing error is 0, cnc motion is not a "real" circle, and also encoders motion <> turret ( or spindle ) motion, since there is a precision lost around the mechanical chain
hi sinha, i know my "accuracies" ...It is not a very accurate statement. The arc starts with the start radius. If it cannot reach the target point due to some inaccuracy, it makes a small linear move in the end to reach the end point, provided the radius error is within the specified limit.
about that "small linear move" :Code:if swd[wo] then t:='G02' else t:='G03'; if full_circle then
... if next block contains an axis move instruction, then the machine won't reach the "end point", but will get close to it until distance < in-position; and there is a big chance to have the in-position > g02 code precision
... if next block does not contain an axis move, or it contains whatever instruction that is telling the controller to reach the end point, then, if there is some inacuracy, the machine will move to the end point, not among a linear segment, but among a "non-interpolated segment", that is executed on such a short distance, that the servos won't be able to reach the programmed feed, so servos won't be in sync, but each one will reach the final point on it's own; is possible that only the servo will rotate, but the turret will be allready stationary; kind of a succumbed motion, when the cnc can't reach the programmed feed / kindly
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg
But less than 360deg. If one were to use the R Format for a full 360deg, a more accurate overall result would be achieved by programming, say, a 359.5deg arc, and 0.5deg arc. However, is there was an error caused by using rounded numbers in the calculation, a shift of the arc centre would still result.
Typical halfwit DK comment.
What Sinha stated is quite correct. You clearly stated in the Post Sinha referred to that both IJK and R Format are shifted. This is not the case with IJK Format as the arc centre is provided by the part program and is not calculated by the control for that arc specified from the Start Point to the Arc Centre. If the End Point specified results in a different Radius to the specified Arc Centre, to that of the Start Point, and the difference is less than a tolerance set in parameter, the action is as Sinha stated,
There is a clear pattern of you making erroneous statements and when pointed out, you come back with waffle that simply highlights your lack of knowledge and makes you appear a bigger buffoon.
actually i did not said that both formats are shifed, but that they may be shifted, thus there is a probabilityYou clearly stated in the Post Sinha referred to that both IJK and R Format are shifted.
again, here is a probability : it may happen, or not; and when it happens, the movement is not an interpolated segment, because programmed feed may not be reached for that short segmentand the difference is less than a tolerance set in parameter, the action is as Sinha stated
you are also so full of wisdom ...There is a clear pattern of you making erroneous statements and when pointed out, you come back with waffle that simply highlights your lack of knowledge and makes you appear a bigger buffoon.
ps: 2252-01 ALARM-B DATA WORD circle calculation A side 1
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg