Work with probe

Here it is on the Pi4 which is connected to a MESA 7i92H. Not sure if the real time delay warning is because I'm also connected via WiFi or if the CAN bus code is taking too much time.

On my side I just renamed psng.glade to psng_1280x1024.glade and made a symbolic link to the file that fit my screen and I have a different panel according to which file I choose.

This might be a better general LCNC question but since it happens inside one of the probe macros I thought I'd start here.

The issue is with manual tool change as parsed in a users g-code like My observations were that the system would move to the tool position.  Move up and then move down again.  It appears as if the commenting this statement out of doesn't seem to make a difference as the manual tool change operation movement is still being done. I determined that behaviour by discovering that there are two XYZ locations for tool changes.  The guide tells us to add this: The guide doesn't tell us to remove these tool change parameters as I have with the '#' symbols By setting the XYZ TOOL_CHANGE_POSITION to a dramatically different position from the [CHANGE_POSITION] shows that the spindle is first moved to that position and then to the [EMCIO] TOOL_CHANGE_POSITION. Commenting those out leaves the spindle at the [CHANGE_POSITION]

I think it's happening because of this in the psng_manual_change.ngc subroutine file.
Why is there in essence a recursive call to the M6 function we are currently in?  I don't understand why that is there.  I suspect that's what results in the use of the [EMCIO] TOOL_CHANGE_POSITION.

Anyone have any ideas about this?
Thanks
John





 

Well, it's not recursive, the remap option load the appropriate code when the program calls M6.
Then, inside the remapped code, it's the original M6 that is called to ensure LinuxCNC is aware of tool change and set all necessary values on the modal state of the machine (tool number, tool diameter, tool length, etc).

If original M6 is not called within remapped function, the tool will not be considered as changed and probably make erratic behaviour after M6 call in main program.

furynick wrote:

Well, it's not recursive, the remap option load the appropriate code when the program calls M6.
Then, inside the remapped code, it's the original M6 that is called to ensure LinuxCNC is aware of tool change and set all necessary values on the modal state of the machine (tool number, tool diameter, tool length, etc).

If original M6 is not called within remapped function, the tool will not be considered as changed and probably make erratic behaviour after M6 call in main program.
 

So the question then is if the loadusr manual tool change line is commented out but there are values in [EMCIO] like TOOL_CHANGE_POSITION why is there a move to that location?  What else is running that probably shouldn't be?  Commenting that out solves the move problem but there are others on the test bench Pi4 where I haven't' re-enabled the loadusr manual tool change.

I'll put together a detailed description of those.  Very strange. 

Hey,
just wondering if there is version for 2.9?