GCODE Scripts for OctoPrint and the UM2+?

[Nicolinux 288]

Hi,

My relation to OctoPrint seems to reflect the shape of a sine wave - I get to it, encounter a problem, forget about it and get back to it several releases later until the next problem occurs

This time I'd like to use it with the UM2+ and have the following scenario:

I'd like to use the gcode start scripts in OctoPrint:

The problem is - these scripts are wrapped around the gcode that is produced in Cura. So if one tries to emulate the start-up sequence of the UM2 in those OctoPrint gcode scripts, it fails because there is no M104/M109 heat-up command. The solution would be to ditch the OctoPrint gcode scripts and use the standard Cura start/end gcode scripts.

So my question is - does anyone use these OctoPrint gcode scripts for the startup sequence? If so - how?

I've posted a question on OctoPrint g+ here:

https://plus.google.com/105898160884424119287/posts/1EEr9z72YEL?cfem=1

[tinkergnome 927]

UltiGCode uses volumetric e-values, i assume, that you have changed the GCode-Flavor in Cura to "Reprap/Marlin", right?

The remaining problem is, that Octoprint has (obviously) no clue about the temperatures that you have defined in Cura (as Mark Walker said: this part is executed after the start script from Octoprint).

You can add values for M109 and M190 to your Octoprint script, but only with fixed values that you have to change for different materials.

As an alternative: you can (pre-) heat buildplate and nozzle manually with Octoprint before you start the print.

But that's sooo inconvenient..., and i'm still not sure about your intention...?

It's so much easier to use the start/end-code from within the slicer.

[Nicolinux 288]

Yes I did set to regular Reprap/Marlin.

And you are right - manually heating up defeats the purpose of having a remote device taking care of the print. If I resort to that I could as well walk up to the printer and start the print from the sd card.

Maybe I'll do something in between. Like set a fixed value in OctoPrint and let the gcode heatup value override it when the print begins. It will only break when the difference between my fixed temp and the gcode temp differ greatly, but ok, you can't have it all

[berndjm 16]

If you have a good-working start- and endcode in Cura I see no reason to use the start/endcode in Octoprint.

The only part I use is "After printjob is cancelled" to force Octoprint sending the normal Endsequence when I cancel a printjob ...