OctoPrint On Air #18


#1

Topics in this episode which was recorded on July 28th:

  • Release of 1.3.9
  • New things in 1.3.10 (detection of more unsafe printers, firmware triggered dialogs) and work towards a first RC
  • Continued work on 1.4.0
  • Q&A session, among other things touching on:
    • plugin activity,
    • user interface,
    • bootstrapping of instances

Full contents with jump marks available in the YouTube description.

You can find all public past episodes in the OctoPrint On Air Playlist.

OctoPrint On Air is a roughly monthly live broadcast done by me (Gina Häußge) for all Patrons on the Patreon campaign pledging at the $5 perk or above. Attendees can ask questions which will be answered on air and I also report what’s been going on in the background, what happened, what the current challenges are and what the near future holds, plus talk about whatever else might be interesting in the world of OctoPrint.


This is a companion discussion topic for the original entry at https://octoprint.org/blog/2018/08/13/octoprint-on-air-18/

#2

Noting that at 20 minutes into the video you indicate that you believe that there are five users in the U.S. which have OctoPrint. :laugh:

March 2018 first three quarters sales: US$4M

Robo3D optimistic for the remainder of 2018

Ryan Legudi, Managing Director at Robo3D is very optimistic for the remainder of 2018. He commented on the results with: “the market opportunity for Robo has never been better. We are operating in a rapidly emerging industry, expected to grow 3-fold over the next four years to reach an estimated 1.9 million units, compared to around an estimated 500,000 units in 2017.”


On a different note, when I left them they wanted me to re-work the UI to undo some previously-contracted work to rearrange all the tab content. So beware of any anonymous suggestions to consolidate the tab content because this might be Robo 3D.


#4

Five users in the US already running a version that has the tracking plugin bundled and who also opted into it - huge difference :wink:


#5

That begs the question of whether I opted in...and I don't remember being asked, but I did an upgrade, not a fresh install.


#6

@supertaz of the maintenance branch (1.3.10.dev) or the devel branch (1.4.0.dev)? If not but e.g. 1.3.9 - no tracking plugin yet. As mentioned in the video, that's something that's rolling out with the next release, not yet available on stable :slight_smile:


#7

Did I just out my time machine? Yeah, it's like 0400 here, so ignore me...need to sleep sheepish grin


#8

The last question in the Q&A was asking about changing settings per layer on prints. Simplify3D has a very robust system for doing this and visualizing it, and can even handle different settings on different parts within the same layer. It is definitely an area that is far better suited to the slicer than during a print, as multi-material prints can have very different settings for materials, some of which would be negatively impacted (for instance, TPU sections and PETG sections of the same part may not be able to tolerate the same % increase in speed or other parameters and maintain similar quality profiles, due to very different material properties).


#9

I have a 27 hour print with OctoPrint. I am running OctoPrint 1.3.9 on OctoPi 0.15.1.
What do I need to change so you get the tracking info? You may be getting the info I printed that one after you made the recording. The only problem that I encountered was the YouTube stream crashed at 9 hours. May have been my internet connection that caused that problem. I like the temp and voltage warnings that you have added to the Nav bar.


#10

@Scottmcf The tracking plugin isn't available yet for 1.3.9 (and that can't be changed since it needs some functionality I only added in the development version of 1.3.10). Will be available once 1.3.10 is released (and in the 1.3.10 RCs) :slight_smile:


#11

I don't remember if you mentioned this or not, but in the cool new features for monitoring power in the status bar, is there also a feature to df -h (one-per-hour or something like that)?

Maybe https://fontawesome.com/v4.7.0/icon/hdd-o for the normal condition and a red version for anything lower than some percentage?


#12

I'd make it update after each upload, instead of hourly. The more you read/write to an SD card, the shorter its life. As long as log rotation is going on, you're not likely to run out of storage faster than an upload hook will catch.

Ideally on a system like a Pi, you'd use a ramdisk and mount the image RO, or RW with the ramdisk being used for anything except adding plugins, changing configs, and storing as few log files as possible, or use storage designed for more access cycles for logging and data files. Since we don't do that, we should at least do what we can not to kill the SD card with extra cycles, IMHO.


#13

Actually, that's a great idea. I designed a system in San Francisco for a company that had computers-in-slots in a rack system and each PC would bootup, create a RAM disk, copy everything it needed into that and ran all day long on that RAM drive. The thing is still working to this day, I'm sure. The standard lifetime of a server hard drive like that is about ten years in production and those were put into place back in 1994. :+1:

The downside on a standard Raspberry Pi 3B is the limited RAM. I think we'd need to go with one of the off-brands for the 4GB version.

Hang on though, OctoPrint is only using 64MB of RAM and for hard drive space we've got (89M for OctoPrint + 137MB for oprint + 35MB for .octoprint = 261MB) or about a quarter of 1GB. There's currently about 340MB of free RAM on mine at the moment and I have Conky, Node and Xorg running so mine's a bit bloated, to be honest. It's currently streaming from the webcam in a browser.

In short, I think it's do-able on a Raspi 3.


#14

May I direct your eyes to the lower right corner of the file list?

image

That will turn red and bold if certain thresholds are met.

Might indeed be an idea though to make a next to full root partition flash up an indicator there though.


#15

If it were a snake, it would have bitten me. Never seen that before until now.


#16

I don't see why it wouldn't be doable. I've run systems that way before, and it makes them near bullet-proof. I'd want to see an instrumented timelapse run's high water mark, but I'm guessing you could do a 128-256MB ramdisk option on an OctoPi image, with all the bells and whistles running. The biggest problem is minimizing logging (basically I'd love to see a big ole toggle in the UI between "minimal logging to disk" and "something's not right, so log everything" for support purposes). The other things would be making sure to offer the option to decide whether to persist gcode and to store any gcode other than the currently loaded file compressed on the ramdisk.

Also, you want a high water mark to make sure you don't EVER hit a low RAM situation...swap on SD is VERY VERY BAD(tm), and linux thrashes like a shark in a kiddie pool if you get too low on RAM.