Communicating lathe and bar-feeder

[Dick1951]

Communcation lathe/bar-feeder


Hi,

Mostly i'm working on a lathe Okuma CNC,connected on a bar-feeder VDK.
The bar-feeder is working with a pressed air driven rod,controlled by valves and some electronics.
It is going as follow;when the chuck is opened,it can be see by the bar-feeder and the rod is comming out.
when the chuck is closed,the rod is going back.
the machines are communicating with eachother.
Its working in all modes;automatic,MDI and manuel.

Probably because all is old and low budged repair,its happens the chuck is longer open because the bar-feeder is getting a new bar, the lathe is going on the program and when i do'nt responsd in time,the machine will be crashed.
The belonging error is only;interrupted bar-feeding.

Because i want understand this proces and i want theck it,i'm asking on which page of the controller it is to see and which parameter it is.
I cant find it.

When somebody can tell me this and spare some time,i would be obliged.
It's about a lathe Okuma LB 15 controll OSP 5000GL and Bar-feeder,branch VDK

Thanks already

Dick.

[littlerob]

I think I understand what is happening, the bar is being pushed too far, then the chuck closes on a long piece sticking way too far out of the chuck when it closes, and the turret is colliding with the bar, right? The easiest way to fix this, is to program a stop in the turret. That way the bar can not come out too far. I do not think there is a parameter change. Maybe I'm wrong. It wouldn't be the first time.

I have never used a feeder that would feed lengths ---only feed against a stop. I would think that it would be a bar feeder issue not a machine issue. I only say that because it would be some pretty intensive variable programming to get that to happen at the control.

[Dick1951]

the bar is being pushed too far, then the chuck closes on a long piece sticking way too far out of the chuck when it closes, and the turret is colliding with the bar, right?
littlerob.
It only happens when the bar-feeder is getting a new bar.
The piece rested is being removed and than the feeder get a new bar and the chuck is always open,the machine is waiting.
when the bar is in its place he is coming out.
Than the machine is going on the program.

The bar-feeder can recognize when the chuck is open or closed and will response, so does the lathe too.
And when the bar is coming out then I stop it with the turret.

There is communication between the machines.

Dick.

[littlerob]

I understand there is communication between the machines. You say that when the feeder is changing to a new bar then the crash happens, you also say that the turret has a stop in it.

I am missing something, the machine will NOT run with the chuck open, so we know that the chuck IS closing on a piece. So obviously the chuck is not closed when the turret moves out of the way. Turn the chuck pressure up. I think the easiest way is to put an M0 after the M12 to insure that everything is right before you proceed. If that is too time consuming, one of the guys smarter than me can write an IF statement that will only stop the program on the bar change over.

Robert

[tc429]

had a similar issue on a bunch of Fanuc controlled korean lathes we scratch built barfeeders for...

chuck overstroke time could be corrected by adding a timer or a lot of other ways, found easier/faster to just move the jaws in a couple serrations so the chuck barely opened past the bar diameter- also helped in holding remnant stub from cocking in the spindle/chuck- just had to taper the rear of the jaws to funnel the new bar in... if using collets, adjusting drawtube length can achieve the same thing.

if okuma uses prox switches on chuck stroke, maybe consider adding a pressure switch in series to be sure the workpiece is tight before moving on...weve had that situation before...

I know nothing about Okumas, we just got in a half dozen of them, still kinda hoping to throw a Fanuc on one one of these days... years back we got in a dozen cinci machining centers, we retrofitted 4 with fanuc zeroes(powermate/macro driven communication for the t/c axis) and those 4 were sped up/uptime was so improved they outran the 8 others with the cinci controls- and parts were dirt cheap compared to most other control brands

[littlerob]

I know nothing about Okumas, we just got in a half dozen of them, still kinda hoping to throw a Fanuc on one one of these days...

BLASPHEMER!!! Why in the name of all that is holy would you make an error like that? OSP is a superior control in every respect, there is not one single feature on a fansuck control that I would prefer. Let me think memory? uhh not even close. OE avoidance, no. Offset changes making any sense? uhh "U1" is .0001 of what, in what measurement system. Or my favorite-------NOT

G76 P021060 Q20 R5*(The first 2 digits in P represent the amount of finish passes, the next 2 are the pullout distance at the end of the threading motion, expressed in tenths of revolutions, the 60 is the angle of the tool)
G76 X1.94 Z-1.0 P300(total thread depth) Q150(depth of first cut) F.05*
R if needed is the amount of taper over total distance in thread motion.
The P value is figured by taking the F-value times the constant of .6, once figured you also have the X value.

I am just trying to cut a threaded part man. Not learn Klingon.

Are you serious Fanuc? Whew, sorry I am done. If you can't tell I loathe Fanuc controls.

Meanwhile back to bar stopping....