[JohnHennessy]

I have gotten this error with code posted with ver 27 and 28 pro. on three different machine controls now. Sometimes its just the first two arc moves in a nest of code and other times it's every damn line with an arc... I have messed around with the machine tolerance in the cam with no help. Has anyone else had this happen? What do I do to fix it?

[aldepoalo]

I have a feeling that this issue has to do with the geometry itself. Where did the file come from, did you import it or draw it in BobCAD?

[JohnHennessy]

I have a feeling that this issue has to do with the geometry itself. Where did the file come from, did you import it or draw it in BobCAD?

Actually its the adaptive roughing tool path that is generated from a simple pocket... I have had this problem before with code from a package called Powerstation as well (2 1/2 axis software) but it was a long time ago and I cant remember just how I fixed it.
I used bobcad to generate the model, and toolpath, I have not noticed it in the toolpath other than adaptive roughing, I try using it on everything, Sometimes its not an issue at all then all of the sudden i'm seeing an error either at the beginning, first couple of arcs, or in the first block of code...

[aldepoalo]

John what controllers are you running and what post processors are you running?

[JohnHennessy]

With the Anilam 4000e, an Anilam 3000e and a Milltronics, Post processor is the stock 3C_3x_mill, also the downloaded Milltronics and Anilam processors. I use the default processor most of the time because I modified it slightly for R values for circle centers instead of I's and K's for ease of reading at the control when looking ahead of a running program. The machines read them no problem. Do you think this could be a problem?

[nlh]

I've had a similar issue with adaptive rough on a Bridgeport Torqcut TC1g. This machine has a DX32 control. My solution or workaround initially was to recalculate and repost with a different stepover percentage, usually going higher or lower by a few percent would fix it. Then I looked at my post and made it break arcs into quadrants, this seemed to work out a lot better. However, this didn't fix it 100%, so I started looking at the code.

Needless to say with a program size of ~100K, it took awhile, but eventually found a spot where the software (BCC V28 pro) was outputting a dual line in the code. This line was an arc with a very small radius. When I removed that second duplicate line, the program worked.

I have had this happen to several programs, so this wasn't the first instance but the most hair pulling to track down.

With the DX32 control, you can't see exactly where in the program the error is occuring, so tracking it down was a lot more difficult than some controls may be. Check to see if the spot where the control is causing the alarm is trying to read a duplicate line.

I don't believe this is a post processor issue, as I have tried several generic ones that came with V28 and all had same result. I also played with arc output, ie R or IJK, with same result. This machine is somewhat new to me so trying to determine if it's a machine problem or bcc issue was pretty difficult at first.

Hope this helps.

[The Engine Guy]

Have you checked the actual machine control parameters for the minimum arc setting?
Some years ago I had a Mill that wouldn`t do an arc of less than 0.7 mm (0.028 inch).

Often within a program where you are trying to use complex toolpaths the software will sometimes create some very small rads in order to complete it`s journey to the next point, this is fine within the simulation but there are times when the actual CNC machine just can`t handle the very small rads.

Just a thought, but I would be looking at my CNC machine controls Manual and Parameters.
May have nothing to do with your issue at all but worth a look IMHO, I doubt it is the software at fault, it is only doing what it has been told to do the best way it can

Regards
Rob
:rainfro: :rainfro: :rainfro:

[JohnHennessy]

The control parameters have a value setting that from what I recall, will not check the code for an error under a programed radius of this size, or maybe any radius with an end point error smaller than this? The Anilam's default is .005. I don't want to change this for a particular software's code to run. If its a code problem, I need to adjust a processor... The control has to many good runs under her belt, not saying its not a control issue it's just not as suspect as a processor at this point.
I've generated and ran several programs today with no problems at all, one was a tapered hole that I spiraled with the software... (stranged code this one) it ran fine as well.. The very next issue I have I'm detailing everything up to and the work around used to get by. I'll present the question with more background data. Thank you all for the time and effort.....