Mazak pausing while drip feeding?

[bhayden10]

Morning all,

I am running a high speed core roughing process and the machine will pause at times, mostly out of the cut just before rapiding up to the next pass. Seems to be worse on the short passes and doesnt pause when the path is long. This is the second part I have drip fed and the first was a contour pass and it worked fine. The machine is a 94 model Mazak 414. Using Cimco editor.

 

Machine --- Computer

G19-2400 --- baud 2400

g20-3-1.5 --- stop bits 2

g21-0 even --- parity even

g22-0 invalid --- parity check

g23-3-8 --- data bits 7

These were the settings we have always used on the machine to download programs, my operator said he had to change the computer to these settings in order for it to work.

I appreciate any information!

Thanks

[Kyle Waters]

not sure, but if you are running drip feed, it would seem that you would want your baud rate quite a bit faster than 2400. or was that a typo.

[Rob B]

Brain,

We also drip feed to a 414. You are probably feeding faster than the buad rate will feed the program to the controller. We had to up the buad rate to 9600.

 

We drip feed using tape mode. The controller has a buufer that will load the program to and use it as the program is needed.

Thismight not make any sense, but hope this helps.

Robert

[Mcam Nut]

Also a very long cable will cause problems, if you can run the program from a laptop at the machine with a short cable, would work best.

[Mcam Nut]

a Baud rate of 2400 seems way to low. what type of control is it?

[titanium neck]

I have noticed that the high speed toolpaths in X2 are quite large output files. Your baud rate does need to be higher in order to get all that info to the controller as it needs it. We run a baud of 19200 and that seems to be able to keep up with the demand on the machine. Hope that helps a bit. If you cannot get your computer and controller to communicate at that speed, you might be out of luck, either way you need a higher transfer rate of info between them.

[Ocean Lacky™]

Another thing to look at if it's not the slow baud rate, check your linking parameters page and make sure that Output Feed Move box is checked IF your not using the full retract option.

 

I had a similar experience yesterday on a Mazak 640 Fusion control and this was the cause.

[bhayden10]

Thanks for all the replies!

Control is M32. When we first tested it on a short engraving program he tried 9600 and 4800 and it ran part of the program and stopped, so he lowered to 2400 and it ran. We'll try to up it again. We are using tape mode also, and we are using a 50' cable, but I could shorten it if I need to because it is on a laptop. It was a cable we had already. I am using min retract, and the box is checked with a 500 in it?

[Mcam Nut]

Shorten up the cable if you can, we run our m32 controls at 4800. I think higher was causing problems on that control, but with a short cable maybe 9600 would work

[Ocean Lacky™]

quote:

---

I am using min retract, and the box is checked with a 500 in it?

---

Ok...it should output a F500. feed move instead of a G0 rapid move. My issue was small increments being output for the entry and exit arcs in a rapid move. it was choking the control.

[bhayden10]

Well i'm back, we shortened the cable to 12 ft. I put the feed from 500 to 180 on the min. retract and tried the 4800 baud rate. It ran part of the first facing op and gave the error "data in out error". We dropped it back to 2400 and it pauses just like it was before. Any other suggestions or ideas?

[3R!< W3NG3R]

you are filtering the toolpaths right?

 

Also, your machine should work with higher baud rates. Ours runs at 19200, and sometimes it can be slow. Double check to see if ALL your machine and the computer settings match 100%.

[bhayden10]

This is my settings on the filter.

[3R!< W3NG3R]

I cannot read that Brian, but it looks like the filter tol is zero. I use a higher value then that. (about .001)

[Guest CNC Apps Guy 1]

At 2400 Baud I'd almost bet money you are feeding too fast. When drip feeding (of course this will depend on the kind of work you are machining - mold and die vs. aerospace airframe for example), if you have a lot of small moves (lots of data) and slow baud (2400 qualifies for this moniker), you will basically be limited to about 20-30 IPM. At that point you'll hit what's called "Data Starvation", meaning you're running the code faster than it can be fed into the control. I'd reccommend putting a PC right next to the machine, get as short a cable as posible, and running up around 19,200 Baud. This will get you up around 75-80 IPM (of course depending on how much data you're trying to push).

 

HTH

[Troy Gossett Indepak Inc.]

If it isn't the cable and isn't the Baud, It may be time to test the memory on the modem board of the Machine, your first clue will be how much data is accepted into the machine each time before it stops.

We had a machine a while back that would only take X amount of code and then it would just wait for more code while it never would get. It was amost exactly the same amount of data each time.

 

I would look at this line:

g22-0 invalid --- parity check

What are the other options?

 

 

What type of cable are you using? Is it shielded? Grounded at only one end? does it run close to any Flourecent(spelling?) Lights, or electric motors, conduit?

[Allan]

I've had similar problems with drip feeding on Mazak, the problem is in handshaking, usually it can be solved by increasing the Baud rate to 9600 or more and setting an end of line delay in your DNC software.

 

EDIT: You will also want to turn off the FIFO buffer for the port in the device manager of Windows.

[bhayden10]

Testing the memory? Is that something I can do or do I have to have a mazak guy come in for that? We are using a pretty high quality cable, It originally came from Griffo Bros, we shortened it to 12' and have the laptop next to the controller so I don't think interferance is a problem, Not sure about the grounded at one end though? I will check the g22 on monday.

I will also check the end of line delay, we are using the trial version of cimco 5 now to make sure it will all work before we buy it. I will check the Fifo buffer too.

Thanks for the continued help guys! I would never be able to get this done without it!

[Jack Mitchell]

Brian,

Cable is 100feet long.

Computer is a POS 66 MHz running Windows 95.

Easytalk software – old but effective.

VQC 15/40 1989 M32 control.

Issues: None

Let me know if you need any other parameters

 

 

G1 .. 2 .. CMT baud 9600

G2 .. 1 .. ?

G9 .. 1 .. force tool data load

G10 .. 2 .. Printer baud 4800

G11 .. 3 .. paper feed lines

G12 .. 66 .. lines per page

G19 .. 1 .. reader/puncher baud 9600

G20 .. 3 .. stop bits is 2

G21 .. 0 .. even parity

G22 .. 0 .. parity check invalid

G23 .. 3 .. data bits is 8

G24 .. 1 .. ?

G27 .. 0 .. placement of CR

G29 .. 3 .. complies with control code DC1 thru DC4

G30 .. 1 .. assignment to DC code to be output

 

Let me know what changes worked for you.

 

Regards, Jack