vmc 760 w/ dx32 post

[archer]

Hello people,

First off, I'd like to say thank you to all that have helped me in the past, there are a lot of talented folks out there. That being said, I've got a problem with our post program for our Bridgeport 760. When we are cutting 3d surfaces, being a cavity or boss, the machine has a lot of jerky movements. It seems like the machine will walk across the shop floor if we don't slow it down from about 40 ipm to 20 ipm. This problem has been evident ever since we got mastercam. The post that we are using in the standard dx32 post with some minor mods to it. I have looked into it before, but with no luck. This problem is not evident on our fadals. For reference, we use to use hand written programs to cut a boss, and could run this machine at 40 ipm without the jerky movements. Any help or ideas would be very helpful.

 

Thank you,

Dennis Archer

Mold Maker

Mastercam V9.1

[mold100]

It sounds like a controller issue are you drip feeding?If so whats your baud rate?

[Roger Peterson]

Reference your controller book against the code at the top of the file. It sounds like an exact stop mode or some type of cut mode to me.

 

 

HTH

[archer]

If drip feeding is also DNC'ing, then yes, most all of the programs are to large to load. The baud rate is at 9600.

 

As for the top of the program, what am i looking for?

[Roger Peterson]

I just posted a simple program out using the mpdx32 and there is a G75. I don't know what this is for this controller, could be inch mode, could be absolute, or it could be some type of exact stop. Do you know what this is? If not check out the book it will tell you. 9600 baud rate should be good for drip feeding. Are you using the filter to arc's in the toolpath? If not give that a try also.

 

 

let us know

[Nominal]

Sounds like data starvation. Chances are your hand written programs from the past didn't have 2 million blocks of code either. At 40ipm the machine gets into position before the buffer is replenished. Either get a controller that can look ahead enough to handle what you're doing or change your linerization tolerance so you get less lines of code.

[mold100]

Does it seem like the jerking is stop and go starvation, I have seen 9600 hundred not process quick enough if the controller cant see that far ahead.Always in 3D. What kind of tolerances to you have set?Sometimes if I would open them up alittle it would eliminate some of this the x,y moves become larger so there is less steps.

[mold100]

Looks like nominal beat me to the punch.

 

Corey teh SSSSSSLlllllllllooooowwwwwww typer!

[CAM-mando]

I agree with the data starvation speculation, does the control support YZ or XZ arcs, perhaps filtering the toolpath could help.

[archer]

A G75 is Multi-quadrant circle input on. I have tried to use filter, but I don't completely understand it. The tolarances that was mentioned, we normaly use .001-.0005. Thats cut tolerance. How can I reduce the starvation. Changing controllers is probably not an option. Does corner rounding have any effect on it? I was just running a pocket on a plate, and used the helix entry method. The machine near about chased me across the shop. So its not just the surfaces.

 

Thanks

Dennis Archer

[mold100]

Just out of curiosity is the machine fastened

to the floor or just on pads?Also is the machine

crossing sections of concrete (like lines in sidewalk)?

[Roger Peterson]

Dennis, I think we know the problem is data starvation. Can you bump up the baud rate on your machine? It sounds like the G75 will allow you to output an arc that is over 90 degrees. Depending on what your surfaces look like you can do a surface finish contour which is a constant z cutting toolpath. With this you can use the filter to create arcs. You could then machine the majority of your surfaces at 40 ipm. You would then have to run a surface finish shallow at the slower feedrate. If your machine can take arcs in the G18 or G19 plane try using a surface finish parralel at 0 or 90 degree cut angle.

 

 

HTH

[Trevor Bailey]

Give the filter a try. You are definetely data-starving. You will need to cut "arcs" whereever you can. You may also have to change your toolpath style because of this. Meaning - pick the toolpath that will give you the most arcs in the posted code.

 

Its not MC, its a control thing. I even have this problem on an older Fadal I have.

[P_Scott]

archer,

 

To find out more information about Filtering, look here surface finish contour topic You could get more information by conducting your own search on this forum. I know filtering has been discussed several times and I would rather not hi-jack your topic here with another filter discussion. HTH

[Ken1958]

We had a Torque cut 22 with a dx-32 control and one way to stop the "bump" at the axis change of direction was to add G09 P.005 line to the begining of the program. I hope this helps

[Chris Rizzo]

I've used an easy way to check for data starvation...while your program is running/dripfeeding, keep lowering your feedrate at the conrol until things "smooth out". If motions get more fluid the slower you go, well then you've got a stavation situation.

 

This also is a quick and dirty way to see how much data you can jam through the cable, but by doing the opposit . Increase the feedrate (at the control) until movements get jerky. Oh, make sure your cutting air for this one!

[Chris Rizzo]

Just another quick thought...(as if my last one wasn't obvious enough!) Can you load a portion of the program into the control, and try running it from there? Just to see if it would run smoothly from the control memory vs. the dnc system.

 

That may make it obvious if you have a posting issue or a drip-feed starvation issue. However it may not determine if the amount of code it still is out-pacing the contol buffer...