"Unknown Operation" when 5 Axis Digitizing

I'm trying to create a set of subroutines which will digitize the inside of an opening semi-manually by placing the probe inside an object around the perimeter of the opening and selecting a subroutine from one of the 12 clock positions. This must all be performed with the A Axis tilted at an angle. B-Axis will always be at 0 degrees when doing this.

The attached subroutines compensate for the kinematics, so that when I want to digitize along Joint 1 it will not not move along Joint 2.

The subroutines for the 3, 6, 9 and 12 O'clock positions work correctly. The 3 and 9 O'clock positions only digitize in the X direction and the 6 and 12 O'clock positions only digitize in the Y and Z directions.

When I try the 11 or 1 O'clock positions (which digitize in the X, Y and Z directions) the subroutine works partially. It will move the probe in the correct direction and make contact with the part. The I get an "Unknown Operation" error and the program terminates. I placed debug points in the code to determine how far it gets and it will only get to Debug Point Zero, which is immediately before the probe command.

Does anyone know what is causing this error, or if there is a bug in LinuxCNC. I was initially using version 2.5.0 and after receiving the error message I upgraded to 2.5.3 but the problem remains.

Hi

Nothing leaps out immediately, but I don't have anything to test it on and the variables could hold anything.

What I would suggest doing is changing your .ini file in the [EMC] section so that DEBUG = 7FFFFFFF

Then run Linuxcnc from a terminal and you will hopefully get some meaningful error messages that will narrow down what is happening
(amongst the reams of other messages )

Since the variables make the actual state rather opaque, hopefully you will get something better than "Unknown Operation"

regards

I tried what you said. This is the debug information I get from terminal:

emc/task/emctask.cc 374: interp_error: Unknown operation
Unknown operation

I can't find anything on the net for a 374: interp_error. What does this mean.

I know the variables make it hard to be certain that the move is valid. That is why i put the debug line in there to show me which direction it will probe when digitizing. I verified that the current point is the same as the programmed point, G40 is active, the feed rate is 20ipm, and the probe is not making contact when it starts.

What is really confusing is that it actually probes in the correct direction, then the digitizer properly indicates that it makes contact while immediately stopping all movement. This is exactly what it is supposed to do. It gives me the error immediately after the axis movement has stopped because it never reaches (debug,Point One).

Since the error is occurring when the digitizer makes contact, is there something i can put in the gcode to ignore the error and finish the program?

I can't find anything on the net for a 374: interp_error. What does this mean.

It means it came from line 374 of emctask.cc, the function print_interp_error() and probably
rcs_print_error("interp_error: %s\n", interp_error_text_buf);
assuming you are using 2.5.3

Unfortunately that does not help much because it is a general error printing function called by lots of other functions

The text comes from a define in rs274ngc_return.hh
#define NCE_UNKNOWN_OPERATION _("Unknown operation")

It is used exclusively in interp_read.cc, but unfortunately its use is as a default when no other error type fits

I will pass on to the developers mailing list, hopefully someone there will have an idea what is happening

regards

Since the error is occurring when the digitizer makes contact, is there something i can put in the gcode to ignore the error and finish the program?

No it is coming from the interpreter reading the gcode, all you can do is try to put all the values as hardcoded etc and check that the results are the same
and it is not falling over some unexpected charactor in a variable

As a test, I hard coded the feed rate and axis coordinates into the G38 command line. I ended up getting the same exact machine response and error message.

Thank you, thank you, thank you. I removed the extra bracket from the three probe location equations and everything works fine now.

Thanks