Laser & CNC Mill/Router support


#1

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.

Cheers,
Fabio.


Whatif Extruder axis is not E?
#2

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

#3

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?


#4

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.


#5

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).


#6

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 templates.tab.entries[]["data_bind"] is that what you meant? Where can I elegantly set that?

Thanks,
Fabio.


#7

Just a short word to say that this is a genius idea, and that there is a ton of potential here. I currently manually edit Octoprint's source code on my customer's machines to do so many things that would just be easy out of the box if this were implemented.


#8

Apologies for the delayed reply.

Should definitely be server side. A hook (not a mixin) should probably suffice.

Not sure about particulars, more leaning towards something like properties. But in general, yes. We might want to make it hierarchical though...

properties:
  commands:
    jog: G0
    extrude: G1
    read_temperature: M105
    set_temperature_hotend: M104
  firmware: Smoothieware
  parts:
    hotend: true
    bed: false

Modelling that might go through some iterations though.

It's hidden in src/server/views.py, where all the core components come together. On the devel branch there's an example on how to set data-bindings there (since we need them there for the granular permissions):

Syntax is the same as for TemplatePlugins (same underlying mechanism).


#9

Hello Foosel,
Thanks for the pointers, I got the databindings somewhat working, on devel they work fine but on maintenance it takes a little more javascript magic to hide the tab link, please take a look:

If that's ok with you I will start PRs for hideTempTab, HideExtrusionContols. For the G0 jog would you like to wait for the profile changes? Should that go to devel or maintenance? devel seems to be way ahead, what is the general cadence that devel ships?

As for "properties" I was trying to keep it as an schema free dictionary so we would be able to extend via plugin, wouldn't that be preferable?

I'll start working on extensible machine types now.

Cheers,
Fabio


#10

It might make sense to simply backport the generalized tab selection magic from devel to maintenance for this instead of going for something temperature tab specific. I believe it was these lines:

Hm... tricky questions :wink:

Regarding the devel release cycle, since there are quite invasive changes on devel (new permission system, Py3 compatibility, and I'm also targeting the new comm layer for that and am focusing a ton of this again now for that reason) that usually takes quite a long time, like, two years+. 1.3.0 was released in December of 2016 and I have to make a 1.4.0 release this year since starting 2020 Python 2 hits end-of-life, so OctoPrint stable needs to be Python 3 compatible before. But I can't tell you if it will be summer or fall, too much to do still.

To get the G0 into maintenance I'd go at it with your original approach and leave the full blown profile refactoring to a later date/devel.

It can still be a schema free dictionary even with a hierarchy. I just want to avoid something like encoding hierarchy into key names when it can live in the data structure (jogCommand, heatCommand, extrudeCommand vs commands.jog, commands.heat, commands.extrude). I'm not saying we should nail down the first level keys, they can still be freeform depending on what makes sense, but the more generalized things that the platform needs to read in order to configure itself properly should have some hierarchy so that I don't go insane maintaining it long term :wink:


#11

This post was flagged by the community and is temporarily hidden.


#12

This post was flagged by the community and is temporarily hidden.


#13

It might be worth mentioning the printer profile(s) that you setup to test this.


#14

I added it to the PRs, but in a nutshell you have to disable the heated bed option and set extruder count to 0.

For reference here are the PRs:


I'll update this code to use the new profile properties once we get that coded up.


#15

Re-posting half of my earlier post as it was flagged as not useful though had some relevant unanswered questions.

By original you mean switch to G0 cold turkey or you mean gate on the new MachineType and leave properties for later?

Thanks again for the time you're spending guiding me here.
Cheers,
Fabio.