lock out some M codes

mikeabuilder

I've just written my first macro that "edits" the boot config. I do this by using M98 in my config.g to call another file with a command in it. In my case it's a G10 command setting the Z offset for a tool. My use case is that after adjusting the offset using baby steps, I want to change the offset in G10 and re-zero the baby steps. Makes it easy for me to adjust the "boot-time" Z-offset without using an M500 (because I'm not sure babysteps get rolled into M500 saves, I want to decide when to save baby steps, and I want the Z offset where I put it (not where M500 saved it). But none of that is the point of this post.

In writing my macros, I was overwriting an existing file that will get run on boot up and it got me thinking about malicious (accidental or purposeful) gcode coming in with a print file - my printer will be available to the public at the maker space whre it lives. A malicious person could overwrite the config.g file with a blank file, or change any part of the config. An accidental person might change the machine max speed, acceleration, jerk settings.

So the wish list is a way for me to block execution of certain M commands from execution in job files after a lock is established. In my case, I can restrict users to bringing files to the printer via the PanelDue SD card, so blocking as part of the "execute job" process is where it would fit.

I think the implementation would be something like a new Mcode that I would call and a parameter that lets me enter another Mcode (or list of Mcodes) to block. A second parameter would let me define the action if a blocked code is found (ignore the line and warn, throw an error and do not execute, other?). The fw implementation would be to preview a job file and act as requested. I think this could be implemented completely as macros run from start.g, but would probably be better in fw.

fcwilt

@mikeabuilder

You normally wouldn't save the baby-step setting. It's for print time adjustment.

Why do you want to do that?

And does this printer have multiple tools?

Thanks.

Frederick

MJLew

@mikeabuilder That sounds like it would be a very good capability. Your use case is perfect, the distribution of ready sliced gcode files from printables.com is another.

OwenD

@mikeabuilder
I can't think of a way that this could be done in macros because RRF has no real string handling functions.
i.e. in most programming languages you could search each line for any occurrence of an M code you want to restrict. All we can do is look for an exact match of the whole line which won't work.
Perhaps on an SBC something may be able to be done.
You also face the difficulty in that anyone who has access to the panelDue also has access to the command line.
IF the firmware could optionally exclude certain M codes, they would have to be stored in a file which could be edited or deleted.
Also you need a way to turn the function on and off.
The last point could be done with a key switch connected to an input.
Another reason to use an SBC may be that you could create a custom interface with no command line.
It could have just a couple of buttons to start/pause/cancel.
The start button would allow you to select a print file which would be run through a pre-processor to remove any "nasties".
The modified output could then be saved and loaded into the duet.

mikeabuilder

@OwenD - oh, yeah - string functions. I'm sure that's already in the wishlist somewhere. And an SBC front end would would allow this but I don't have one. My real concern is less about intentionally malicious gcode, and more about some slicer custom gcode or future slicer feature that wants to set things that I want the printer to control. My initial set are the max speed accel, jerk settings, but other thing maybe in the future (like hot end temperature settings).

@fcwilt - One tool at present. As I work on my printer, I find myself fiddling with the print head and then needing to re-calibrate the tool offset. Before my macro, my method was to use use DWC to update the Z offset setting after fiddling with feeler gages, small Z movements, running a test print. AND the DWC part entails running back into the house where the computer is. With my macro, I fiddle using the feeler gages and a test print, making Z adjustments with the baby steps on the PanelDue. Then I run my macro that reads the current Z offset, the current baby steps and rewrites the Z offset command macro with a new offset that incorporates the baby step adjustments. No running back and forth into the house, upsetting the cats and my wife. I can fit up everything via PanelDue. And still use baby steps for fine tuning during a print, then decide if I want to roll those baby steps into the offset or not.

fcwilt

@mikeabuilder said in lock out some M codes:

@fcwilt - With my macro, I fiddle using the feeler gages and a test print, making Z adjustments with the baby steps on the PanelDue. Then I run my macro that reads the current Z offset, the current baby steps and rewrites the Z offset command macro with a new offset that incorporates the baby step adjustments. No running back and forth into the house, upsetting the cats and my wife. I can fit up everything via PanelDue. And still use baby steps for fine tuning during a print, then decide if I want to roll those baby steps into the offset or not.

When you mention Z offset are you adjusting the Z Probe Z Trigger Height or the Tool Z Offset.

With variables and conditional code it's easy to update either one, for the duration of the session. And with M500 you can persist them for the next session.

That strikes me as simpler and more reliable then creating a macro file on the fly.

The firmware already provides the capability you need, let the firmware do the work. No need to re-invent the wheel.

Just my take as a retired programmer. Feel free to ignore everything I posted.

Frederick

mikeabuilder

@fcwilt - good points about using the sw functions already provided and I'll admit that I have not looked for a tutorial on "how the fw is intended to be used in normal operation". I'm also a retired engineer and my instinct always makes me ask "why doe it need to be done that way?" and "can't I do it this other way just as well?". Those questions lead me to really understanding how things work which I think is what I'm really after.

So my method of managing my printer is to have the Z probe offset always equal to 0. I also set the minimum Z to be -4mm to allow room for the bed to move to the nozzle location.

Then I find the tool's Z offset as described above.

But you say "With variables and conditional code it's easy to update either one, for the duration of the session." I'm not sure what you mean.

My macro looks like this:

;If no tools is selected, prompt the user
if state.currentTool =-1    ; menas there is no tool selected 
  M291 P"No tool selected. Select tool first." S1 T0
  M99


; Read the current baby steps
var baby_steps = move.axes[2].babystep  ; Positive babystep means the bed is farther from the nozzle

; Read the current tool offset
var current_Z_offset = tools[state.currentTool].offsets[2]

; Calculate the new tool offset
var z_offset_new = var.current_Z_offset - var.baby_steps

; build the command string
var command = "G10 P"^{state.currentTool}^" Z"^{var.z_offset_new}

; clear the baby stepping
M290 R0 S0

; Create the replacement for the tooloffset file 
echo >{"tool"^state.currentTool^"_Z_offset.g"} {"; This macro sets the Z offset for tool # "^state.currentTool}
echo >>{"tool"^state.currentTool^"_Z_offset.g"} {var.command^"  ;changed: "^state.time}


; run the new z_offset file
M98 P{"0:/sys/tool"^state.currentTool^"_Z_offset.g"}

It's a little more than needed, with calling of the macro file it creates, but it's pretty simple. And I guess I could have skipped having it create a new macro if I used the if I put an M500 P10 at the end of this one.

fcwilt

@mikeabuilder

Rather then create a new file to execute a constructed G10 command you can simply have a pre-existing file with G10 command(s) using variables for the values you wish to be able to change.

You set the variables to the desired values and execute the file. Or you could pass the values as parameters to the file.

That persists for the duration of the session. To persist the settings you simply execute M500 P10.

You are obtaining the same result but with the extra code for creating the file each time you wish to change the values.

In either case you have the macro and the file with the G10 command(s) which needs to be executed.

Frederick