Stop program if no tpost.g for called tool has not been defined

infiniteloop

I would expect the program to stop/cancel and an error message if a tool is called and no tool change macro has been defined for that tool.

Instead of changing the default behaviour, having consequences for many 3D users who rely on the fact that a non-existent macro does "nothing", I propose to write protective code for undefined tools (6-9?):

; tpost6.g
M0 ; stop

MaxGyver

@infiniteloop

An empty tpost1.g would still do nothing. And an empty tpost1.g is already present after a fresh install if I recall correctly.

infiniteloop

@MaxGyver

An empty tpost1.g would still do nothing…

… jus as a missing tpost1.g - that's consistent

OwenD

@MaxGyver
Although I don't use CNC, I can agree that from a safety point of view perhaps the firmware should check for the existence of these files if in CNC mode and halt if the don't exist.

In the mean time you can get something like it by using the object model.

In each tfree# put something like

var nextPreFile = "0:/sys/tpre" ^ state.nextTool ^ ".g"
var nextPostFile = "0:/sys/tpost" ^ state.nextTool ^ ".g"
var thisPostFile = "0:/sys/tpost" ^ state.currentTool ^ ".g"
var nextFreeFile = "0:/sys/tfree" ^ state.nextTool ^ ".g"



if !fileexists(var.nextPreFile)
   abort "File not found: " ^ var.nextPreFile
if !fileexists(var.nextPostFile)
   abort "File not found: " ^ var.nextPostFile
if !fileexists(var.nextFreeFile)
   abort "File not found: " ^ var.nextFreeFile
if !fileexists(var.thisPostFile)
   abort "File not found: " ^ var.thisPostFile

Note this hasn't been tested.
It would also require RRF 3.5.0b1
It requires obviously that tfree0.g exists

Edit
You probably should check for the post file of the current tool
You should also account for cases where the next tool is -1 (no tool)

T3P3Tony

@OwenD said in Stop program if no tpost.g for called tool has not been defined:

perhaps the firmware should check for the existence of these files if in CNC mode

I am personally not keen on divergence between CNC mode and FDM/General mode when its not needed. We are increasingly seeing mixed mode machines for hybrid manufacturing.

OwenD

@T3P3Tony said in Stop program if no tpost.g for called tool has not been defined:

I am personally not keen on divergence >between CNC mode and FDM/General >mode when its not needed. We are >increasingly seeing mixed mode >machines for hybrid manufacturing.

Totally understandable and acceptable to me.
Just the increased debugging requirements are a major disincentive to any divergence.
The object model gives use the ability to do lots of things, including even the use a single tool change macro, but in the current state, there must at least exist the files for T0 as they are the only "trigger" that's accessible.
I would suggest that the configurator could perhaps initially generate CNC tool change files (for all defined tools) that paused and/or slowed movement by default, but it sounds to me that in this case the tool was likely defined manually so that doesn't help either

I guess CNC users must assume a certain level of responsibility that they're operating dangerous equipment.
I've personally seen a (industrial sized) router throw a 200mm square piece of 12mm aluminium about 10 metres with enough ~~torch~~ force to punch through the metal shed wall.

MaxGyver

@OwenD said in Stop program if no tpost.g for called tool has not been defined:

I guess CNC users must assume a certain level of responsibility that they're operating dangerous equipment.

On this I absolutely agree. I have been the witness and cause of more than one CNC-related mishap on industrial and hobbyist equipment. But shit happens...

I have never had the case where a Toolchange in the Gcode did not trigger any response on the controller side.

Most Cam software I have worked with automatically number the tools in the library. With other CNC-Controllers this is not a problem.
On our router with a industrial controller for example it is impossible to change a tool without having the according offsets defined or a toolsetting/ probing routine in place. This is absolut standard procedure for every CNC-machine I have worked with so far.

T3P3Tony

@MaxGyver said in Stop program if no tpost.g for called tool has not been defined:

Most Cam software I have worked with automatically number the tools in the library. With other CNC-Controllers this is not a problem.
On our router with a industrial controller for example it is impossible to change a tool without having the according offsets defined or a toolsetting/ probing routine in place. This is absolut standard procedure for every CNC-machine I have worked with so far.

This is also a good point. the current way of defining a tool allows for significant latitude for the user to define one without completing the requisite tool change files.

The config tool creating files with safe defaults (basically stop and provide a message to the user that they need to configure them) would be a step forward. but does not catch the cases where they are defined after the fact which is probably common.

Changing the behaviour to throw an error if the tool change files do not exist could make sense for all users (CNC & FDM). It would still rely on the user to put something in those files.

If any one reading this has an example of where requiring the files to exist (they could be empty) would be an issue it would be interesting to have that added to the conversation. (paging @deckingman for your input where you have a lot of "tools" but one extruder).

deckingman

@T3P3Tony said in Stop program if no tpost.g for called tool has not been defined:

..........(paging @deckingman for your input where you have a lot of "tools" but one extruder).

Keh? My case is one nozzle but multiple extruders but essentially two different types of configuration. The first is combining filaments of the same temperature characteristics which can have up to 6 extruders but many more tools. In this case, about the only thing that happens between tool changes might be a purge and wipe. But depending on the print, this isn't always necessary so I tend to post process the gcode file to run a purge/ wipe macro, rather than use the tool change macros. In this case, the tool change files are empty and it wouldn't matter if they were missing. The second configuration type is different filament types requiring different temperatures. In this case, there are again 6 extruders but no combinations so only 6 tools. In this case, all 3 tool change macros are required and essential for all 6 tools.

But given that users can do pretty much anything they like with tool change macros, I don't see much point making it a prerequisite that macros exist for every tool. If the macro contains mistakes or spurious commands, bad things are still going to happen. In fact, I could think of quite a few scenarios where doing nothing would be better than doing the wrong thing. Just my twopence worth seeing that my name was mentioned.

T3P3Tony

@deckingman thanks for the response, just mentioned you as I knew you had a bunch of different tools that we not physical tools.

MaxGyver

I would like to give this thread a little push.

Yesterday I had another crash because of this issue. Although I was aware of the issue this time, it still slipped my mind to add a new tpost.g in RRF when I was configuring new tools in my CAM software. I have about 30 tools in my library right now, and I would really like to avoid adding 50 tpost.g to my system folder just to be safe...

deckingman

@MaxGyver What do your tool change macros actually do and are they similar for every tool? The reason I ask is that I use the same "universal" tool change macros for every tool. The "universal" part is taken care of by using gcode meta commands and conditional statements - i.e. things like "tools[state.currentTool.name", and "heat.heaters[1].current" etc. These macros are named "ToolFree.g", "ToolPre.g" etc. Then every tfree(n).g simply has one command which is M98 P"ToolFree.g". Of course, one still has to create files for every tool but at it's a much simpler process.

EDIT - more info here if it's of any use https://forum.duet3d.com/topic/29646/universal-tool-change-files-on-steroids?_=1675705608001

MaxGyver

Is it possible to include object model parameters in an M291 message box?
This would allow me to use the same tpost#.g code for all tools.

"^ state.currentTool ^" works within an echo command, but not in M291?

M5 ;stop spindle
M291 P" " R"Please load Tool#""^ state.currentTool ^""" S4 K{"OK","Cancel"} ;display message box with "OK" and "Cancel"
  if {input=1} ;
    echo "Toolchange cancelled, terminating programm..."
    M2 ; end programm
  else ; continue macro if user presses "OK"
    echo "Tool#"^ state.currentTool ^" loaded"

OwenD

@MaxGyver
You need curly braces around the parameters if you wish to have it evaluated as an expression

M291 P" " R{"Please load Tool #"^ state.currentTool} S4 K{"OK","Cancel"}

MaxGyver

@OwenD

Thank you!

This is the most recent version of my super simple universal tool change macro:

M5 ;stop spindle

M291 P" " R{"Please load Tool #"^ state.currentTool} S4 K{"Continue","Cancel"} ;display message box with "Continue" and "Cancel"
  if {input=1}
    if state.status="processing" ;check if a programm is running
      M2 ; end programm
      echo "Toolchange cancelled, terminating programm..."
    else 
      echo "Toolchange cancelled..."
  else ; continue macro if user presses "Continue"
    echo "Tool#"^ state.currentTool ^" loaded"