Dialog 11, Radius Deviation Too Large gcode made by Featurecam. How can I solve this?

Dialog 11 on a Deckel FP50CC/T

I am breaking free of manually writing CAM and am having trouble. I have done a few CAM programs and wrote a few post processors, but am now branching into using an old version of Featurecam. I have been spending some time converting a Dialog 4 post processor to Dialog 11. It currently runs cycles, arrays of holes, and standard moving operations.

I am consistently having "Radius Deviation Too Large" when I test it on the Deckel. On other machines which had this error I forced the CAM to not do curves and do straight lines, but those cases I was using a modern computer to drip info and a different CAM program. I don't know how to force Featurecam to make straight lines.

Below is the g-code start. It is hung up on N120.


I am currently unsure of how to fix this. Most post relating to Featurecam link to HSM, which has a different post processor format (.cps vs .cnc). What do other people do to make CAM for their Dialog 11s?

Autodesk has a post for Fusion 360. Maybe take a look at that. I have no idea whether it is any good. Their Fusion post for Dialog 4 needed a lot of work to make it work. I guess nobody QCs this stuff.


Sent from my iPhone using Tapatalk

A shot in the dark here because I don't know Featurecam or D11 - I had obscure errors on circle quadrants long ago on an Acramatic control with smartcam and edgecam, It turned out to be the endpoint of one arc was not close enough to the beginning point of the next arc or line, The arc centers and angles and radii varied just enough that the endpoints were far enough apart that the control couldn't make the leap to join them - something on the order of .001". This sort of sounds similar. I found it by reverse engineering the G code line by line. I resolved it by forcing the code accuracy to a closer tolerance.

Think Rich is correct.
Supplied posts are usually pretty poor ...Program makers are depending on the user being current and they will "tune" the post to your needs. Program out of maintenance and you are on your own.

Don't know about your CAM or specifics to Dialog 11, but would try and insert a G64 at the program beginning. In D4 this is a modal command...which will cause the control to "blend" the contours so that exact start and end points are averaged...might help here.
Have no idea if the D11 uses this , works to eliminate herkey,jerkey moves on the D4....

Cheers Ross

I tried a G64 but no luck so far. I have used it before when I was doing a large contour map.

I'll do some searching to see if there is a way to increase the tolerance in Featurecam. See if I can get six decimal place accuracy so the Deckel can round it the way it wants.

I faced this problem with an old version of HSM on a dialog 4 control.It was occuring only in "adaptive clearing" method of cutting where optimal movements are selected by the CAM.On a chat I had with a programmer he suggested tunning the program tolerances and accuracy on the settings.This is not so bad, because its a roughing method.

Vitran said:

I tried a G64 but no luck so far. I have used it before when I was doing a large contour map.

I'll do some searching to see if there is a way to increase the tolerance in Featurecam. See if I can get six decimal place accuracy so the Deckel can round it the way it wants.

Click to expand...

In Dialog 4, G64 only works within G41/G42 cutter radius compensation in the control. In Fusion or HSM, if you choose compensation in the computer, rather than the control, G64 won't apply. In HSM, compensation in the control (G41/G42) is only applied during finish passes, not during clearing. That's why I can write much nicer-acting D4 code by hand than what comes out of Fusion, but that is time-consuming to say the least.

Thanks for the help, but still no luck yet.

I laid out the rotation and it is wrong. It does an arc from X3.38785 Y3.25 to G3 X3.37286 Y3.46373 I-1.53030 J0. By doing the equation by hand and on the computer, it should be I-1.531195, a difference of almost a thou.

Seems an issue in the calculator or the precision of the arc fitting. Not sure what I can do to make it up. May mean I can't use Featurecam if I can't do an arc.

I did make it partly work, but I think I broke it too. I changed the G values from XYIJ to XYR and that works. Issues come that it has the same spot twice with a radius at the start and end of every block of code. Wait, now that I think about it, it must be making a circle to come back to itself. Crud.

I was dreaming last night and I found the cause of the issue, however unsure why it showed up. I tested it this morning and it worked like a charm.

The Dialog 11 controller, for arcs, is G2/G3 X# Y# II/A# JI/A# where A is for absolute and I is for incremental. The post processor for the Dialog 4, which I based my code off of, did not have this A or I. Without the I or A, the processor will assume absolute, resulting in the error in the code.

Good catch...
If you are programming off a CAM system don't think that having the option to use the "switch" to define the circle center is of any value..just go with running everything absolute....

Now i can see times where having the choice on the center definitions would be nice for some hand coding...
Cheers Ross