Raspberry Pi 3

[martin-bienz]

If the print is started from SD, you can't monitor the progress from OctoPrint anymore as it can't "attach" to the printer while it is working.

Right, it is the one or the other.

For the printer, printing from SD or from USB is a totally different process, so you cannot suddently decide to send a pause from USB while printing for SD.
Also when the line is opened (through USB), the Arduino board will reset. It is the way Arduino works and there is nothing you can do from the software side.

OctoPrint is a (very nice) alternative to other USB printing software (like Cura, Repetier Host, ...) and like these it replaces the controller.

If you just want a monitoring solution for SD card printing OctoPrint won't help, just use a webcam, you can then possibly use a berry to remotely switch the power off or connect a gpio pin to the UltiBoard and trigger an event (custom firmware required )

This is only partially correct . What I do (and also octoprint), I open the serial port from the pi to the UM on start and keep it open. You are then free to query the serial interface whenever you like, also while printing from SD. So you just need to make sure that you do not re-connect the serial port. So a PI restart while printing will reset the Arduino => mess up the print.
With M105 and M27 I get the status for Temp and also status in Bytes printed of total. You can then of course also pause, stop etc. using GCODE.
For the record, I like octoprint, but I wanted to keep printing from SD card and at the same time make Timlapse pictures. Octoprint had no way of starting stoping a Timelapse on the fly (maybe now it does), I even created a feature request, but that was not accepted AFAIK. So I wrote my own little python application that does that. I have just yesterday posted a picture of the web frontend in another post: viewtopic.php?f=34&t=139#p1435 (scroll down).
The code of my application (pretty messy) is not really ready for production, but if someone is interested I might make an exception .

EDIT: the progress bar you see on my application is purely bytes printed vs. total bytes => so this is especially in the beginning of the print waaay of as the first layer prints normaly slower etc.

[reibuehl]

Could you share more about your OctoPrint setup Martin? That sounds very interesting

[martin-bienz]

yes, reibuel, I can. It is NOT octoprint, it's my own application (but similar), I will write a bit about it later in the afternoon.

[nilrog]

Looking forward to that. This looks way more useful than a full OctoPrint installation

[Amedee]

This is only partially correct .

I think we do agree

My main point is you can't use OctoPrint as simple monitoring application, and whatever what you are using you can't connect during a print.

Now if you write something yourself and ensure you stay connected this is another story - I saw your pictures this morning and I have to say: well done

Looking forward to that. This looks way more useful than a full OctoPrint installation

Again depending what you are looking for. If you still want to play with SD cards (what I can understand if you are an UM2 user) OctoPrint is indeed not what you need.

But for UMO users (or if you don't care about UM2 profiles) it is a great solution.

[martin-bienz]

I think we do agree

Absolutely

Again depending what you are looking for. If you still want to play with SD cards (what I can understand if you are an UM2 user) OctoPrint is indeed not what you need.

But for UMO users (or if you don't care about UM2 profiles) it is a great solution.

Yes, correct. And octoprint, especially on a Pi2, works absolutely great, so it's really work looking at! Let me maybe elaborate a bit more why I decided NOT to use OctoPrint on my UMO.
So when I started to install OctoPrint it was in it's "children shoes", do we say that in english also, it's a german expression but you get the point? It worked well from the beginning, but NOT with the RaspiCam (not a OctoPrint fault, btw, but mjpeg-streamer, which is now not a problem anymore), nor was it very relliable (gcode streaming), I have a few instances of failed prints. The first Pi's were simply not up to the task. But the main thing for me was the ability to create Timelapse pictures (start and stop manually, on request, start and stop when a print starts / ends). Also I wanted a way (light) of monitoring the printer while printing with as much information as I could get from the serial interface. I decided to go with SD - Printing, as to me it's a bit safer, when you switch the pi of / freezes midprint, it still continues to print (just don't start it again with the usb cable connected).

That's basically it. I then implemented more features over time, as the bootstrap interface was working nicely with mobile browsers and in gerneral it works rather well. Features like, send me email when the print is done, switch on the light wenn print starts, switch off when done, implement a pygame interface to work nicely with small screens (like the PiTFT 2.8) to be a able to control things directly from the printer (not webinterface) and a few more . I am currently also testing my own "change filament" routine that could be done on the Pi vs. Marlin (in short: pause print, store coordinates, move away, change filament, restore coordinates, resume) but I am nowhere...no time.

I will write more tomorrow (or tonight)... sorry, I need to go.

[Amedee]

Yes, I understand your journey. I started as well with an old B and early versions of OctoPrint and I gave up as well for the same reasons.
Then I tried again with a B+ (and more recent version of OctoPrint) and I haven't stopped since then.

Never had a failure, last reboot was last year when we had general power failure in the street (and no, my printer is not on UPS...)

[nilrog]

Looking forward to that. This looks way more useful than a full OctoPrint installation

Again depending what you are looking for. If you still want to play with SD cards (what I can understand if you are an UM2 user) OctoPrint is indeed not what you need.

But for UMO users (or if you don't care about UM2 profiles) it is a great solution.

I have an UMO+ (soon to be fully operational). The printer will be placed in the garage so i'm going to need some kind of remote monitoring. I'm not so sure I want/need all the "fluff" from OctoPrint. I anyway need to go to the printer to start the print so I will probably use SD-cards to print from. That's why I think this solution looks nice.

I had OctoPrint installed on my Pi just to check it out. So I will probably take it for another spin to see how it works when connected to the printer.

[Amedee]

Maybe it is just me, but I hate this SD-Card thing
It is so convenient to drag and drop the files directly on my computer.

But don't get me wrong, I am not trying to sell OctoPrint here, Martin has a great solution as well.

[martin-bienz]

Maybe it is just me, but I hate this SD-Card thing
It is so convenient to drag and drop the files directly on my computer.

But don't get me wrong, I am not trying to sell OctoPrint here, Martin has a great solution as well.

In probably 95% of the cases, octoprint will do perfectly well for your requirements! Just install it and try. BTW: you can also kick an SD - Card print from within octoprint and monitor it. The features are really great, I think Gina did a fantastic job. I would recommend trying it out if you did not. You will not require an SD - Card anymore.

I repeat myself by saying I did create my application because I wanted something a bit more flexible / lightweight (the octoprint web client is a little chunky especially for mobile, but works well) when it comes to Timelapses... and I like coding stuff myseld. If you look at what I have implemented, it's quite similar to what Gina did at the end of the day, but of course it has things, that are specific to my needs (like the lights, custom serial interface, sending email on completion (with jpg attachement), pygame interface...).

So, if you want to try something different, and / or you like some of the features, I am happy to share my code with you (personal, not / not yet public). Amedee, you can also try it just for fun if you want, even if have not activated gcode streaming, not sd-card upload .

[jonnybischof]

Me likey
I think this could be what I want to power my 3D printer electronics board.. Now that you get the wireless connectivity, it is really worth using it!
I wasn't sure about the Pi handling a printer's GCode queue, but I suppose if an 8bit Arduino hunkajunk can do it, then a Pi shouldn't have any issues in the first place.

[martin-bienz]

Me likey
I think this could be what I want to power my 3D printer electronics board.. Now that you get the wireless connectivity, it is really worth using it!
I wasn't sure about the Pi handling a printer's GCode queue, but I suppose if an 8bit Arduino hunkajunk can do it, then a Pi shouldn't have any issues in the first place.

Which part? Are you planing on using octoprint on the Pi3? Well the Pi2 can handle this really well allready, with the Pi3 and ble, wifi included, we are really getting there. Or are you saying you would control your fancy, new interface board directly with the pi3? interesting idea... (but real-time and linux on the pi... not really, rather beaglebine or similar, but you allready knew that )

[jonnybischof]

Well - IF - at any point this project makes it from paper into the real world, then I'm planning to use the Pi to interpret the GCode and fill a buffer on the custom electronics board. All the real time stuff, PWMs, motor controls and such will be handled by an FPGA which is very well suited for that task. The Pi only needs to be able to fill the buffer faster than the FPGA emptying it. I don't see a problem there, even if the Pi would be busy for a few milliseconds from time to time.
I'm thinking about using an actual RAM buffer which could be large enough to store big amounts of movement commands. Once the buffer is filled, the Pi could even be busy for several seconds without risking a buffer underrun.

What still troubles me is the whole software part. I can do VHDL programming, but the Pi-related stuff, GUI and stuff like that, are new to me.
It would be really nice to have a little webserver on the Pi that displays a webpage with the full configuration and status outputs from the printer. This page could then be displayed by any device in the network, like a smartphone or tablet that you can take right next to the printer.

Btw, we are going off-topic here
I'm still grinding the thoughts, maybe I'll open up a topic when I'm ready to continue the project.