Circular Parameter Inadmissible error, Brings robot to a halt.

If this error is happening on the teach pendant, it might have something to do with your $CIR_TYPE or $ORI_TYPE parameters. I would make sure they each have a value assigned to them and that $ORI_TYPE should probably not be assigned the value #JOINT.

I would also double check the start, end, and auxiliary coordinates for the circular motion and make sure they are all printing from RoboDK as expected.

Hi Asylum,

Let me know next time you face this issue. I'll take a look.

Jeremy

if you have a problem with code, post the (sample) code. top of the program and few lines before and after offending circle.

Quote from Asylum2021

Hi panic mode, I have attached a picture of the controller unit displaying the lines at the point of failure but unfortunately I don't have the top of the program. When we inevitably encounter the problem again I will make sure to post it here (our tech was overwriting the files each time instead of saving them so we lost the older files).

Well, in that screenshot, it's pretty obvious -- the XYZ values for the midpoint and endpoint are identical down to a fraction of a mm. That is guaranteed to cause the error.

You also said the error occurs when you try to move from one layer to another -- are you talking about a vertical move? Such a move should be a LIN, or maybe PTP, not a CIRC -- are you using CIRC moves in places where they are not appropriate?

don't know any of those product but... i am pretty sure there is a way to select granularity of output (steps size), choice of permitted instructions etc.

it is easy for any interpolator to generate code with ultra fine step size and you will get huge file even for shortest paths. but... what is reasonable here?

if you have a path segment 0.1mm long, would there be much of a difference if that 0.1mm segment is a straight line or an arc? if you run 10x CIRC and 10x LIN over same distance, would you be able to tell which product was machined with CIRC and which with LIN motion type?

and if aux point is equidistant from start and end points, you get two arcs of about 0.05mm. and this is an approximated motion (using C_DIS), so length of approximation segments cannot be more than 50% or about 0.025mm. ask yourself how this compares to accuracy of your robot (KR210). since points are so close, i would try to see settings that disable use of CIRC command. just use LIN and let the approximation do it's magic.

what is the output of the Alphacam software?

As panic mode mentioned the distance between point is quite important!

This is simply causing problems and taking time (I had about 300,000 points before and about 65,000 points after data reduction (only LIN movements). I got nice circles and the job was done in 25 min instead of 60 min)

Is there a way in Alphacam to reduce the number of points (not CAM specific but robot specific)?

Normally it is done the following way:

CAD->?->CAM->GCODE(?)->PP->Data reduction->KRL

In your case is this also the way?

Who is doing what (Alphacam or RoboDK)?

Hi Asylum,

I think I helped you somewhere else, either via email or on our own forum, pointing you towards those settings.

For those interested, you can change the minimum step size in mm and deg and the minimum arc size in mm or deg by following these steps:

"Tools"->"Options"->"Program".

In this case, the root of the problem comes from Alphacam. You should be able to find some settings that would prevent Alphacam from generating g-code with points or arc that are too small.

The solution used here is more of a patch RoboDK applies to the program before generating it, the real solution would be to prevent Alphacam from sending that kind of information.

Jeremy