Laser & CNC Mill/Router support


Hello Guys,
Octoprint is quickly becoming the best way to drive many types, including cnc lasers and mills that use the common 3d printer controllers.

I would like to start contributing by coding up a few changes to make those uses less clunky, they are mostly small but quite useful.

A few examples is hiding the temperatue tab and extruder controls for machines other than 3d printers, another common issue is jogging with G1 as on some lasers that turns the laser on, G0 would be preferable.

I know I could bend over backwards and make those as plugins hiding HTML elements of hard coded names and making a gcode filter to intercept G1 jog, but after looking around these changes would be much simply made in OctoPrint and I assume could open it for a lot more uses and users.

So the main point of my changes would be to add two more attributes to the Profile, one for machine type (Printer, Laser, CNC) and another one for Firmware/GCode flavor: (Marlin, Repetier, Smoothie, GRBL, Other).

With those we could add simple checks around OctoPi and plugins to better behave depending on machine type and Gcode flavor.

What do you think?

Here are some of the changes I already made while toying with these ideas:

Any feedback is welcome on these as well as the nicest way to hide the Temperature tab for machines with no heaters. Best I found was Settings.Appearance.Disabled.Tabs, but that seems to need a restart.



Absolutely. I think you've got the right idea.

I've seen attempts at terraforming the OctoPrint interface with a complete overhaul which ended up so ugly that nobody could work on it. Getting some toggles into OctoPrint itself would be preferred in this case, I'd suggest. But then again, I'm not the one doing PRs so foosel would be the person who should weigh in here.

I'll review these today and try to give some feedback.

  • You might want to also consider plotters (here, here, here)
  • I'm considering creating a printer design which will extrude food-grade inks on top of a latte
  • I'm considering creating a printer design which will extrude either just flux or flux + powdered solder so that circuit boards can be prep'd for reflow soldering
  • You could use something like this to pick/place electronic components (SMD)
  • In theory, you might be able to use OctoPrint as a 3D scanner


Yes, absolutely, the plotters you linked have yet another special cases that could be gated on the Profile.MachineType, that way reducing the risk of such changes to the other machine types.
Once these are in the profile we can slowly start addressing each of these scenarios.
@foosel What do you think?


Extending things to other types of machines than just printers has been something I've been wanting to do for a long while. Putting something like a machine type into the printer profiles would be a logical first step to achieve that.

What really rubs me the wrong way though is calling them "printer profiles" in that case though :sweat_smile: Machine profile would be more fitting. Would mean quite a number of wrappers though to keep things backwards compatible on the APIs, but IMHO that would be worth it. Could be something down the road though.

Taking this further we'd also need a way to make the list of possible machine types extendable and thus the evaluation of what to support more flexible, so that we don't do something like "show temperature tab if machine is a printer" but rather "show temperature tab if machine supports temperature control". I see you've already gone this direction with your control tab adjustment. Reason for extendability and flexibility here: There are people out there using OctoPrint for things like lathes, pick-n-place-machines, drawbots, ...

Taking a look at your proposed changes up there, fine by me with some minor changes which I've annotated to the commits. Considering that at least those three actually qualify as improvements rather than a full blown new feature I'd even be tempted to say we'll put those unto the maintenance branch to have them live with 1.3.11.

Regarding the question on how to hide the temperature tab, that should only need a change to the data bindings of the whole tab really to hide it. We might have to backport some tab selection magic from the devel branch to still select the first visible tab in such cases on page reload, but other than that it should be fairly straight forward.


It would be awesome if the /api/printerprofile response allowed this to be queried in a consistent way.

I don't have one of those cool Prusa MMU2s or a Palette+ but maybe this could also be identified (if it's not already).


Thanks for looking Foosel!

I have the itches too, once I started thinking of the machine type concept I started seeing all this stuff in the UI that would need to be renamed to better reflect that, but scoping to a small change now will make it easier to slowly make OctoPrint machine type agnostic, hopefully with some community help.

Good point on making the machine types extensible via plugin, I can incorporate that on my changes.
Do you think we should make it an AddMachineType method on the printerProfilesViewModel? Or should we add it server side somehow? new mixin hook?

I see your point on the machine types having overlaps where temp control, extruders, or tools not being exclusive to one type or another, and we don't want that mapping from type to ability to be hard coded. My changes reflect that conflict as I proposed the machine type laser but then commuted the control UI based on extruders being present(which I think is a better signal). That also becomes relevant when choosing the command for jog, home, probe, level, etc. Maybe it could be extra configurations on the machine profile. But I felt that going that direction would not only clutter the profile settings ui but also the profile code...

Should we plan to have an unbounded dictionary for machine specific config and let the plugins manage it? Something like profile.particulars["hasHotEnd"] = true; profile.particulars["jogCommand"] = "G0"; profile.particulars["firmware"] = "Smoothieware";

I looked for some data binding I could do for the Temperature tab but the template temperature.jinja2 contains only the tab contents, not the tab itself and that threw me off. I see now in index.jinja2 where the tab is generated that I can inject something using[]["data_bind"] is that what you meant? Where can I elegantly set that?