extra arguments for web actions
something with the printer name would be super handy, I've got multiple of the same model, and would like to be able to differentiate them a bit easier
What do you mean here? In web action definition you can assign it to a printer already so it only appears in the printer menu and not in global menu.
When you call it as command you can already add a parameter to the receiver.
yes, but to identify the printer, I have to have gcode specifically for that printer, passing it's name off as an argument. Tt would be nice if I could pass say $PRINTER_NAME as an argument to the web action, so all heterogeneous models can use the same gcode and still identify the device. The use case here (and I may just be doing this wrong) is sending notifications at the beginning and end of the print. The model name would be useful for me as well, but honestly I could just do with being able to identify the printer.
That was horribly written and I apologize. Let me restate.
Getting notifications on print start and stop (for whatever reason).
I can currently accomplish this by using web actions and generating gcode for each printer and associating it with that specific printer. But since I have several of the same model, I was hoping to use one generated gcode file for all of them, as I've adopted a project-centric workflow (for both stl and gcode storage) to minimize duplication. I would like to be able to just have a single web action, that would allow something like $PRINTER_SLUG to be passed off for easy identification.
I fully recognize that I may just be using the system improperly, and feel free to point out my idiocy if that is the case (otherwise I might think it was clever and do it again).
Ok, that requires variables in gcodes. This is something on the todo but can not say for when. I want to also use it e.g. for
and add equations with variables to make most of it. So need a real parser that compiles each line quickly. Also I guess it is only a limit number of lines with this.
Oh nice! yeah that sounds like a pretty killer feature. Understandable on the inability to guess at a time-frame. Software dev work is often pretty hard to pin down in terms of time. Regardless of when, I'm looking forward to that feature when it get's here.