implementing a slicer checker

o_lampe

It would probably be the easiest to use the printer name? You can choose the same name as in the slicer and it's part of the ObjectModel (network.name), so can be used to identify it.

mikeabuilder

These are great suggestions, but one element escapes me. The scenario I'm trying to reject has two conditions. First, the user selected the wrong printer in the slicer (or their own slicer) so the custom code section in the slicer is not present (No variable set). The second condition is that the printer is already running (so config.g will not be run as part of the print process).

I was hoping their might be a gcode file (called something like pre-print.g) that would be run before each print job, and I could insert the config.g code that @fcwilt suggested into that. I was thinking something like this may already be in the code somewhere.

T3P3Tony

@mikeabuilder said in implementing a slicer checker:

a gcode file (called something like pre-print.g) that would be run before each print job

yes. its called start.g

add the file to the /sys/ directory and if it is present it will be called before every print job:
https://duet3d.dozuki.com/Wiki/Macros#Section_Start_pause_stop_and_power_fail

The issue is that its called before the print job so nothing in the print file will have had a chance to run to set a variable that this is a file for printer X or Y.

Others may have a better idea, but one would be to have a check in deamon.g that checks if the printer is in state "processing",(i.e. printing) and if it is then checks to see if the special variable is set to the right value, and if its not then cancels the print and alerts the user. You could use stop.g to unset the special variable at the end of a print.

mikeabuilder

@T3P3Tony - Thanks for this, and the pointer to the wiki page (and HUGE thanks to all those that have created this whole wiki, it's one of the best wikis I ever used. So much good info.). The macro discussion there is excellent.

And you pointed out the key element, which I had not fully groked. I really need something that will do the logical test after the gcode I include in the custom code at the start of my print has run. Some blocking some logic that the custom gcode in my print would unblock. Tricky.

fcwilt

@mikeabuilder

Every slicer does things a bit differently but most include the needed information in the .gcode file generated.

For example here is some of the "file header" generated by Simplify3D:

; G-Code generated by Simplify3D(R) Version 4.1.2
; Oct 29, 2021 at 7:28:14 PM
; Settings Summary
;   processName,FT5 90
;   applyToModels,MoSys - Cable Bracket for Frame
;   profileName,FT-5 TBO=555 SPD=90 (modified)
;   profileVersion,2021-10-14 21:59:01
;   baseProfile,Folger Tech FT-5
;   printMaterial,PLA
;   printQuality,Medium

The problem is there is currently no way I know of to access that information. The firmware could be modified to read the header and extract certain information but it would difficult to keep up with the different slicers and their different versions.

As mentioned there is a file that is run at the start of each print but it occurs before any slicer generated code is run and thus doesn't help.

Frederick

zapta

If I got your requirements correctly, you want to set your printer such that it will reject print jobs whose gcode file doesn't contain an evidence that it was prepared specifically for that printer (or printer type).

Is this correct? If so, something along these lines may work:

Set on the printer a daemon.g script that will periodically check for violating conditions. E.g. Printer is in 'printing' state and some variable X does not have the expected value Y. When this happens, the daemon will abort the print with some error message.
Add in your slicer job start gcode that will set variable X to value Y. This can be an explicit value you choose (e.g. "my_duet1") or one of the slicer's placeholder values (e.g. 'printer_settings_id' with prusa slicer).

Does this address your requirements?

I solved it in a different way, having a single printer.

BTW, having programmatic gcode access to the metadata attributes in the gcode file is an interesting idea. You may want to file a feature request here. AFAIK RRF already extracts some values from those attributes, I think related to layer height, but am not sure.

OwenD

@mikeabuilder

In Prusa Slicer you can access the printer "name" with the {printer_settings_id} placeholder.

If you set up your PrusaSlicer profiles to match the name given in M550 in your config.g on each machine, then it should be relatively easy.

In your PrusaSlicer start Gcode you could have something like

M98 P"check_printer_name.g"  S"{printer_settings_id}" ; this will call a macro and pass the printer name as a parameter

In your macro on all of the printers you have

; check_printer_name.g
if param.S != network.name
    abort "G-Code file does not match printer"

EDIT:

You can also set prusa slicer to put the printer name in the filename (go to output options)
However there's no way to parse the filename to extract it.
It does make it easy when looking at files on your PC though.

There is also a placeholder called {printer_model}
However for a custom printer, it is not filled by default.
You can add a name by editing the *.ini for each of your printers.
This will be located in
%appdata%\PrusaSlicer\printer
on a windows machine.

Search for printer_model = in the ini file

T3P3Tony

@mikeabuilder yes, at this point you need something outside of the current macro for starting a print that RRF provides. All the slicer based solutions work for only part of the usecase (where you have control of the sliced files and can insert the code to check the printer ID into that slicer generated gcode) they don't work for the unknown gcode file.

For now the daemon.g option is the way to go for complete coverage of the usecase.

A feature request to pull named metadata from the file, prior to printing would be a good suggestion but I could not say how soon we could implement it right now.

mikeabuilder

Thanks for all the thoughtful responses. I'll work on a feature request and submit through proper channels. I think I'll ask for a named macro that runs after the print header is processed but before additional lines, and that named metadata in that header be available at that time. I can think of a few uses in addition to my use case.

T3P3Tony

@mikeabuilder thanks. best place is intially a post in the firmware wishlist category here.