Expand profile inference to other common slicers

[nickgabbard]

Is your feature request related to a problem? Please describe.
For a very homogenous print farm that is using pre-sliced Gcodes, it's very annoying to have to select a printer profile for each job I add the queue, especially if I'm not using gcode that was produced by a slicer that CP will attempt to auto-detect the profile. The profile is always the same in this scenario because all the printers in the farm are exactly alike.

Describe the solution you'd like
There should be an option in the configuration page that allows you to choose a profile to apply automatically if one can't be detected from the gcode. It should probably have a warning about the print issues that it could cause if all printers in the queue can't use particular profile.

Describe alternatives you've considered
I have considered manually modifying 2000+ .gcode files to inject lines that would be recognized by the function that automatically detects the profile. Although, I can't get automatic profile detection to work with Kiri Moto with Target Prusa.i3.MK3S+

Additional context
Add any other context or screenshots about the feature request here.

[smartin015]

Hey @nickgabbard - thanks for opening this issue. LAN printing is still somewhat early stage, and I want usability to improve as it's a bit rough right now. Out of curiosity, could you answer

1. What printer make/model are you using for your farm?
2. How many printers do you run?
3. What slicer(s) are you using?

My setup is fairly small, so I rely on other folks to tell me how the plugin is performing with different / more advanced setups.

Re: a default profile option, I'm trying to strike a happy balance between "easy to add work to queue" and "hard to cause permanent damage to printers". Auto-assigning profiles is IMO almost as dangerous as not doing profile validation on submission in the first place, especially for folks with heterogeneous print setups (and if/when someone turns a homogeneous setup into a heterogeneous one).

What do you think about instead having some auto-populated buttons appear on the confirmation modal based on which printers are visible on the network, where clicking a button assigns that profile to all sets in the job before it's submitted? If your setup only has one type of printer, you'd only see one button for that printer type - so functionally, it'd be no more work for you than if the profiles were already automatically assigned (the confirmation modal appears either way, you just click your printer's profile button to submit the job).

In the future when LAN jobs are more editable (see Ultimaker/CuraEngine#101) I hope to remove the confirmation modal. In that case, you'd still see a modal for jobs with unassigned profiles, but otherwise could skip the modal in cases where the profile is inferred.

Another option would be to create a manual tag you could add to your slicer GCODE settings that would be detected by profile inference and set the profile in that way. Of course, this would only be useful for new prints (not your thousands of existing prints).

[nickgabbard]

Happy to work with you and provide answers:

1. Prusa MK3S+ printers
2. About 20 are running at any given time.
3. PrusaSlicer

I agree that a default profile option has the potential to be very dangerous. I feel like if it were somewhere in the options, you would want at least a few dialogs/confirmations/are you really sure's....

As far as auto-populated buttons go, I feel like that would be useful for certain scenarios, but it would still be for every single print loaded to the queue. Our particular use case doesn't make much use of the sets/jobs configuration as it's all a very print on demand setup. Each gcode is an order component and the order processing that gets done on the front side basically delivers a list and says "print these gcodes and put them in a single box." In our use case, each "job" is a single copy of a single gcode. All the printers are physically located in the same place so orders with multiple prints are combined on the spot.

Removal of the confirmation modal is desired. Perhaps make the confirmation modal a configurable yes/no option.

The end goal would be able to use the api (we are using a n8n automation setup for a lot of things in regards to order processing) to directly add a job to the LAN queue through the API without ever using the octoprint interface.

Adding a tag to existing gcode is very do-able. They process like text files and it would be super easy to script in adding a line. I actually tried to figure out what would have triggered the profile detection from Kiri Moto and add it to a gcode file manually. I assumed it was this line "; Target: Prusa.i3.MK3S+" but it didn't seem to detect the profile (either on the file I manually added it to NOR a file that I generated with Kiri Moto). I attempted to debug why, but I got distracted and sidetracked. I don't know if it's specific to that printer model or not.

[smartin015]

Thanks for the cluster details! It's good to hear LAN printing is doing well with a cluster of that size. Also, I'm a bit jealous :)

I agree that a default profile option has the potential to be very dangerous. I feel like if it were somewhere in the options, you would want at least a few dialogs/confirmations/are you really sure's....

As far as auto-populated buttons go, I feel like that would be useful for certain scenarios, but it would still be for every single print loaded to the queue. Our particular use case doesn't make much use of the sets/jobs configuration as it's all a very print on demand setup. Each gcode is an order component and the order processing that gets done on the front side basically delivers a list and says "print these gcodes and put them in a single box." In our use case, each "job" is a single copy of a single gcode. All the printers are physically located in the same place so orders with multiple prints are combined on the spot.

Gotcha - it's perfectly reasonable to have one file/set per job, especially with a setup such as yours.

Removal of the confirmation modal is desired. Perhaps make the confirmation modal a configurable yes/no option.

The end goal would be able to use the api (we are using a n8n automation setup for a lot of things in regards to order processing) to directly add a job to the LAN queue through the API without ever using the octoprint interface.

After Ultimaker/CuraEngine#101, I plan to extend the auto-add setting (under "behaviors" of CPQ settings) to allow selecting any of the configured queues on that instance, with no API work needed. The submission modal can also be removed as well, since it's far less permanent an action.

Adding a tag to existing gcode is very do-able. They process like text files and it would be super easy to script in adding a line. I actually tried to figure out what would have triggered the profile detection from Kiri Moto and add it to a gcode file manually. I assumed it was this line "; Target: Prusa.i3.MK3S+" but it didn't seem to detect the profile (either on the file I manually added it to NOR a file that I generated with Kiri Moto). I attempted to debug why, but I got distracted and sidetracked. I don't know if it's specific to that printer model or not.

Got it - the origin of the GCODE is determined by string matching here - if ; Generated by Kiri:Moto is present it'll then search for the ; Target:... line in the header. If you want to explore this a bit, you can try any of:

1. Abuse the KiriMotoProcessor and inject the two matchable strings (as above) via script
2. Contribute a PrusaSlicerProcessor - should really just be a copy-paste of the existing processor with different matching strings, then add it to PROCESSORS on line 53.
3. Provide an example gcode file so I can do (2) above, on my own time

I'd happily merge in a PR for another processor, especially since PS seems to be pretty common nowadays.

[nickgabbard]

So, I ended up using Option 1 in the end, which is working just fine. I attempted to create my own Processor, but I couldn't get it to work. Didn't have a whole lot of time to debug and figure out why when option 1 was a pretty easy script fix.

For reference though, here is an example from PrusaSlicer.
mk3s.zip

The "created by" tag ends up on line one.
; generated by PrusaSlicer 2.4.2+win64 on 2022-08-22 at 01:21:14 UTC

but the actual printer model doesn't make it into the output until line 189607 and is formatted as
; printer_model = MK3S

[smartin015]

Since you found a mitigation, I'm going to convert this issue into "have better slicer support". Top 3 slicers per this post on all3dp are Cura, Simplify3D, and PrusaSlicer... that seems like a good start.

[smartin015]

Beyond the PR I just merged for PrusaSlicer support:

• I opened Exported GCODE files do not indicate the printer for which they were sliced Ultimaker/Cura#14283 to discuss adding profile data to Cura slicer gcode files.
• I opened Add printer / print settings profile to .gcode header comments slic3r/Slic3r#5148 to discuss adding the same to Slic3r gcode files
• Asked a friend to try slicing with Simplify3D (paid software I'd rather not purchase) to get an example gcode file

[smartin015]

I poked the slicer bugs, as well as the friend - no update otherwise.

[smartin015]

Probably going to ignore Slic3r integration at this point - the last PR was submitted December 2021 (almost year ago). Cura has had a few closed in the last 10 days, so I'm more hopeful.

Update: slic3r maintainer got back to me, said the "Notes" field of slic3r is sufficient to manually describe the printer, e.g.

; printer_profile = "Awesome RepRap Printer"

I should add a generic detector that can be configured for all other slicers.

[ferm10n]

Hey! I should have access to Simplify3D v4, are you still trying to get a sample gcode?

Note that the latest is v5, which I'd need to buy an upgrade for. It's about 50% less $ to get it without the upgrade, but if it helps this project it'd be worth it IMO

[smartin015]

Hey @ferm10n - if you can, that'd be great! Any gcode file will do, as long as I can examine the header to see if there's anything I can use to infer the type of printer being used.

I'd happily take a sample from either v4 or v5, since there's zero support for S3D right now. Thanks!

[ferm10n]

Here's a 3dbenchy, I just installed simplify3d and selected the prusa i3 mk3 profile, but I doubt that matters. What you're looking for is probably on the first line :)

https://gist.github.com/ferm10n/b3c5e86057b7a5dd4c4fb05d2c33add5

[smartin015]

Thanks, this is perfect 👍🏻

Note to myself for when I'm working on this issue in the near future future: I can use the first line

; G-Code generated by Simplify3D(R) Version 4.1.2

to identify the slicer as S3D, and the line

;   profileName,Prusa Research Original Prusa i3 MK3

As fodder for string matching the printer profile

[smartin015]

https://github.com/smartin015/continuousprint/releases/tag/2.4.0 is now live and adds support for S3D profile selection.

Slic3r brushed my request off with "use the Notes field", which is fine.

Cura said they'd look at it, but it's been 5 months. I'll keep this open until that's resolved.

[smartin015]

Cura merged my PR for adding a printer comment to the generated GCODE - it should be available in Cura V5.5 (not yet released).