Threading/OSP 5020L

[Jmooresshop]

I am threading in the IGF mode. I need to enter 11-1/2 TPI and I cannot figure it out. I can only program with IGF. I am not good with entering G code. It is a 2" NPS thread. How do I get a half number entered?

Similar Threads:

• LB 15II osp 5020L
• Okuma OSP 5020L
• osp 5020L monitor went out!!
• 5020L Not booting
• OSP 5020L

[deadlykitten]

hi jmooresshop i played with a newer version of igf, in metric ( milimiters )

it is possible to switch between tpi and pitch size, and in pitch is possible to input a number that is not an integer

i don't have experience with your machine, but i would input in igf 11 tpi, and after that i would edit the code and replace 11 with 11.5

if it would work, it means that the G code can handle a number that is not an integer, but igf uses a filter for integer

if it would not work, then i would change the arguments of the G code ... i will experiment with this tomorrow, on the machine / kindly

[Jmooresshop]

I tried to modify the g code but it doesn't like my changes. I uploaded the g code as it is before editing.

hi jmooresshop i played with a newer version of igf, in metric ( milimiters )

it is possible to switch between tpi and pitch size, and in pitch is possible to input a number that is not an integer

i don't have experience with your machine, but i would input in igf 11 tpi, and after that i would edit the code and replace 11 with 11.5

if it would work, it means that the G code can handle a number that is not an integer, but igf uses a filter for integer

if it would not work, then i would change the arguments of the G code ... i will experiment with this tomorrow, on the machine / kindly

[Superman]

not sure if IGF would accept it
.. but try 23/2

[Jmooresshop]

I changed the 11 to 11.5 and removed the M7 and 3. It worked fine after that.

I tried to modify the g code but it doesn't like my changes. I uploaded the g code as it is before editing.

[deadlykitten]

hi, that "M7 and 3" is an M73 ( Infeed pattern ) which is used together with M33 ( Zigzag infeed ) to generate something pretty similar to attached image

it seems that on your control is not possible to use J=value<>integer + M73 and M33

however, if you wish to achieve that movement, i can code it for you

this is another reason why i love custom infeed paterns and stuff : actually is all fine, until you hit a case when you realize that you are not in full control; i stopped using G71 a while ago, and all my threading codes are using G33 + whatever pattern


for me is much easier and faster to code a thread in G33 than test your code or write this post kindly

[OkumaWiz]

Superman is spot on. F2 J23 is your solution. No decimals are allowed in the J command, but F can definitely be 2.

Best regards,

[deadlykitten]

Superman is spot on. F2 J23 is your solution

hello mr wizard yup, i am also pretty sure that he was saying exactly the same thing ...

No decimals are allowed in the J command

seems that J11.5 worked only after removing M73 ... hmm, a bit strange, and i guess i will test it soon

i just read again attached paragraph from G71, and at 1st glance, it seems that J should be an integer, but this is more an interpretation, because it is not clearly specified

I changed the 11 to 11.5 and removed the M7 and 3. It worked fine after that

hey jmooresshop, try also to replace M22 with M23 ( check attached ) :
... if there is no thread relief, this will smooth out the disengagement of the tool from the material
... also this should help reduce the shock associated with turret going among X near the thread end; however, if parameters and code are not corelated, there may be some disadvantages like downtime; i can develop this if you wish / kindly

[deadlykitten]

on my lathe, this code delivered a pitch=0.5, even if F & J arguments are real numbers or formulas

however, i am concerned about the depth of cuts, because i specified D=0.300doc and U=0.100finish, and this was the output ( pls check attached ):

0.300 ... 0.300 0.200 0.200 0.172 0.053 0.037 0.038 0.100

blue numbers represent those transition passes between D and U, that are calculated by the controller accordingly to the infeed patterns

generally is all fine, until chatter appears sporadic ( on some intermediary passes, or on non-consecutive parts ) and/or last transition passes have a lower doc then the finish pass, etc

i am not saying that cycles are bad, but sometimes a particular case will require a different approach, and that approach should deliver full control over the passes & infeed, otherwise trials time may increase drastically / kindly

 
    G50 S2000 M867

    G00 Z250

    T+5*101 M66 G97 S1000 M03 M42 G00 X55 Z5 M63

    G71 X45 Z-25 D0.3 U+2*0.05 H5 F4.678 J4.678*2 M33 M73

    G00 Z250 M05 M63

    M02