Marlin command M109 S160 not working correctly  

RE: Marlin command M109 S160 not working correctly

Posted by: jack

[...] But back to the issue: I have a Pi Zero W sitting inside my printer that has a program that asks the printer for temperatures and gets them. It can also issue real-time G code commands back to the printer. Perhaps the loop can be closed in that Pi Zero with the right software. Beyond my programming capabilities, but I could write a good spec for one.

Have you played around with Octoprint? It provides a famework for this sort of thing. I haven't done any programming with it yet, but I know that you can inject gcode into the print stream and interpret responses. The "octolapse" plugin used to do all those neat time lapse sequences is a good example.

RE: Marlin command M109 S160 not working correctly

Does Octolapse pause the printer and move the nozzle out of the way; or does it just snap a camera at set intervals during a print?

Seems timing of such things from two ports is begging for problems if the firmware isn't really aware of the fact it has two masters.

RE: Marlin command M109 S160 not working correctly

Posted by: Tim

Does Octolapse pause the printer and move the nozzle out of the way; or does it just snap a camera at set intervals during a print?

Seems timing of such things from two ports is begging for problems if the firmware isn't really aware of the fact it has two masters.

My overly-simplistic understanding is that Octoprint is parsing the gcode stream that it's feeding to the printer via USB for specific gcode patterns that trigger a snapshot event. These can be per-layer or on time intervals. Octoprint is the sole master in charge of issuing each gcode line -- I may have incorrectly implied it was "intercepting" commands -- so it just adds the required gcode to move the nozzle where desired before taking a picture from a camera attached to the RPi. Octoprint seems somewhere between a pre-processor and run-time interpreter, depending on how you configure it. As such, there's only one master, just one that adds a sprinkle of extra commands. I've just touched on using Octolapse, but there are a lot of people getting some very (very very) good results with it. 

Other than the caveat that you need an adequately-powerful host to run it on, Octoprint is pretty straightforward. The part cancelation plug-in is particularly impressive and welcome when one part detaches while printing a full plate of parts. If you need gcode capabilities that go beyond the basic startup, end and layer switch capabilities offered by most slicers or firmware, it's an interesting "coprocessor" option. I'm debating whether I want to move my startup and end gcode to Octoprint. 

RE: Marlin command M109 S160 not working correctly

I just installed my $5 Pi Zero W a few days ago, and have only used OctoPrint a few times. One problem I had is cancelling a job: OctoPrint just hangs at the "Canceling..." screen and does nothing. The printer is confused, and has no obvious way to abort the job from its menu. Turning everything off and on eventually seems to reset the printer and OctoPrint, but not always. So for now I'm back to using my Toshiba FlashAir card, even though the Prusa doesn't recognize it's installed upon power-up.

I'm debating whether I want to move my startup and end gcode to Octoprint

Bob, I did port my startup code to OctoPrint, but only a half-hearted attempt at it. I was confused by what I saw being sent to the printer, and the problem I described above with canceling a job made me stop using OctoPrint for now.

RE: Marlin command M109 S160 not working correctly

Okay - that makes a lot more sense.    So Bob,  now that you've used it for a while, how robust is the USB I/O, or if are you using it, the I/O pin interface?    I've read enough "My printer stopped and I don't know why?" posts that are Octopi related... 

RE: Marlin command M109 S160 not working correctly

It looks like plugins for Octo are Python?  But there is also some javascript?  Hmmm.

RE: Marlin command M109 S160 not working correctly

Posted by: jack

I just installed my $5 Pi Zero W a few days ago, and have only used OctoPrint a few times.

Just keep in mind that the RPi Zero is considered under-horsed for Octoprint. Unfortunately, the Mk3 design and initial release seems to have been not long after the Zero release, and there were a lot of assumptions that the Zero was just like a small 1B (single core). Unfortunately, the Zero W is different in that USB and wifi share/contend for the USB bus, so a great feature proved to be unusable. Note that the new RPi 3 A+ is more than powerful enough to run Octoprint successfully. I'm eventually going to get a new case and camera mount printed for mine.

One problem I had is cancelling a job: OctoPrint just hangs at the "Canceling..." screen and does nothing. The printer is confused, and has no obvious way to abort the job from its menu. Turning everything off and on eventually seems to reset the printer and OctoPrint, but not always.

It can definitely get confused if you reset the printer using the front knob, for example. You mostly have to click an acknowledgement in the web GUI. I've had it get lost a couple of times, but a printer reset has fixed most of those. This infrequent problem is more than offset by the ability to cancel a job remotely IME, so I'm not overly concerned. I have had as many issues printing via SD (random stops and pauses).

Octoprint WILL support printing from SD. I haven't had a chance to play with this much (nor much motivation to do so), but I believe it will let me launch a card uploaded (via Octoprint) to the SD card rather than internal (RPi) storage and regain all the front knob capabilities, albeit at the cost of losing all the nifty Octo remote capabilities except monitoring. Hope to play with this soon and will post an update.

So for now I'm back to using my Toshiba FlashAir card, even though the Prusa doesn't recognize it's installed upon power-up.

OMG. OK, don't get me going on that blasted FlashAir. THAT thing cost me incredible amounts of time, only to fail after a year! YMMV and all that but... grrr.

Bob, I did port my startup code to OctoPrint, but only a half-hearted attempt at it. I was confused by what I saw being sent to the printer, and the problem I described above with canceling a job made me stop using OctoPrint for now.

My thinking is that it makes more sense to create a good startup routine once in Octoprint and have it work with every slicer and every printer configuration in PrusaSlicer without having to maintain them separately. I bounce around between PrusaSlicer, Cura, ideaMaker (infrequently) and Simplify 3D (rarely these days). Keeping track of the different placeholders and capabilities for each is annoying, plus I think I can some more functions in Octoprint (e.g. basic match for slicers that don't support gcode syntax).

For example, I've got a little library of a dozen test prints that I like to pre-generate for each filament type (PLA, PETG, NGEN) that I use, for each nozzle size (9) that I use. I find it handy to have a "Life Adjust" style Live-Z print ready-to-go for example. I've scripted the build, but there are 300+ little gcode files generated. I hate re-generating them whenever I tweak my startup gcode.

I haven't gotten far enough into Octoprint to be anywhere near competent, but I believe it would be possible to set it up to monitor and react to just about anything that can be queried via gcode or by parsing the printer's serial output. This, along with the ability to parse gcode before and during print is intriguing. Things like a truly flexible prime line routine to avoid wearing out that little strip come to mind.

Oh, and the spaghetti detective is also something on my todo list!

RE: Marlin command M109 S160 not working correctly

Posted by: Tim

It looks like plugins for Octo are Python?  But there is also some javascript?  Hmmm.

That is true, but it's not a hackish conglomeration of random code. Octoprint is a full-blown app with server-side and client-side components. The entire thing runs on a full Linux (Debian-esque) distribution, so it's a "real" computer in every sense. I may have some details wrong, but I believe:

• The Octoprint app itself is written in python. From the bit I've looked, it is well-written and maintained Python. Should be a welcome relief after wasting time with C++ recently!
• The Octoprint app is run from the nginx web server, which provides "internet strength" security and performance features. This keeps the Octoprint developer from having to try to keep up with security patches and features for yet-another piece of software. Nginx powers most of the web sites I visit.
• The Octoprint web interface is written in JavaScript. I'm not sure which JavaScript framework it's based on, but this allows it to work on everything from cell phones to HDPI displays without having to write multiple versions. The javascript is squirted to the client when loaded and executes on the user's device. (The promise of Java's "write once, run anywhere".)

Each piece is separate from the others, so can be modified without causing a complete collapse. This sounds like a lot, but the idea of having a full-stack web app running on my cheap little single-board computer next to my 3D printer, each of which would've cost tens of thousands of dollars a decade or two ago, is immensely appealing. I am finding very little that I don't like about Octoprint that the developer (Gina) can do anything about.

RE: Marlin command M109 S160 not working correctly

Well, I just ran two experiments using PrusaSlicet 2.1.0 alpha1 and OctoPrint 1.3.11 from IE:

Experiment #1:

(1) Using my standard start and end g-codes in PrusaSlicer, I sliced the model and uploaded the resulting g-code file to OctoPrint.

(2) I started the print job from OctoPrint, and it executed normally with all temperatures being set corectly. Success.

Experiment #2:

(1) I copied my start and ending g-code scripts from PrusaSlicer and pasted them into OctoPrint. I then deleted those scripts in PrusaSlicer.

(2) I re-sliced in PrusaSlicer and uploaded the new g-code to OctoPrint.

(3) I started the job, and the printer properly executed the command "M104 S160" sent from the OctoPrint start g-code, but the command "M140 S[first_layer_bed_temperature]" failed to change the bed temperature on the Printer. Looking at the OctoPrint terminal, it sent the exact command, but the Prusa could not figure out what first_layer_bed_temperature was, so it left it at zero.

(4) I tried to cancel the job from OctoPrint, but it hung again. The printer was stuck at "heating" because the temp it was waiting for was set to zero.

(5) I turned off the printer at the switch, then back on after a while. Took three times, but eventually it came up normally, waiting for commands.

(6) I closed IE, then reopened OctoPrint and it came back up still in the "Canceling ..." mode. I closed and opened it again, and it came up in "Safe Mode" because it detected something wrong in the previous session, I guess.

(7) At this point, I declared OctoPrint non-operational in my house, at least the way I have it installed and have tried to use it. It's inability to cancel a print job is why. Secondly, it does not appear to process commands that have embedded placeholders correctly. I'm back to the FlashAir until it fails, then I'll just use the dam SD cards.

RE: Marlin command M109 S160 not working correctly

octoprint can't know what you have installed in the slicer as values to set in placeholders because those parameters are not  in the gcode file that octoprint receives.

RE: Marlin command M109 S160 not working correctly

 "M140 S[first_layer_bed_temperature]"

[first_layer_bed_temperature] in a value defined in Plicer. Octoprint has no means to evaluate it, thus you'll need to define it within Octoprint.

The same goes for ALL placeholder names in the custom gcode you are importing.

I think many Octo user only want the remote monitor or selfie aspect of the program.  Any real/serious/programatic added functionality is not a motivation for them.

RE: Marlin command M109 S160 not working correctly

This would be a plugin sort of functionality methinks.

RE: Marlin command M109 S160 not working correctly

Posted by: jack

[...] (3) I started the job, and the printer properly executed the command "M104 S160" sent from the OctoPrint start g-code, but the command "M140 S[first_layer_bed_temperature]" failed to change the bed temperature on the Printer. Looking at the OctoPrint terminal, it sent the exact command, but the Prusa could not figure out what first_layer_bed_temperature was, so it left it at zero.

I'm not trying to convert you to Octoprintism, but I just wanted to point out that:

1. As others have noted, [first-layer_bed_temperature] is only meaningful to PrusaSlicer/Slic3r.
2. That was passed to the printer which took it as 0.
3. It was the printer that hung. Short of a reset, there's nothing much you can do when it gets into that state. 

(4) I tried to cancel the job from OctoPrint, but it hung again. The printer was stuck at "heating" because the temp it was waiting for was set to zero.

While you can't cancel the job in Octoprint, you can't really cancel it anywhere else but at the front panel with any other tool. I've botched gcode before and had similar hangups. I'm not even sure a Cancel print from the front menu is functional when that sort of hangup happens. On the road so can't test.

I should have elaborated a bit more in my previous post. In order to port my startup gcode over, I'll need to do a bit of work if I want it to remain "smart". I'm thinking a plugin to determine what slicer was used on the file and parse settings from the gcode would be a place to start. 

RE: Marlin command M109 S160 not working correctly

I found the perfect tool for failed prints: