I'm not entirely sure what version this "bug" started to present itself, but as of Cura 2.3.1 it is definitely an issue. I never store material temperatures in my GCODE. Partially because I like to change materials a lot, and mainly because even among PLA or ABS suppliers, filament varies and I often find that 5-10°C differences in my material printing temperatures are needed depending on filament brand. My general workflow is to design a part, export it as an STL, slice that STL in Cura, and then store the GCODE file inside of OctoPrint for future reprints of that part, without needing to re-slice in the future. For that reason alone, storing a material temperature in the GCODE itself makes little sense. Cura's process of selecting the model, printer, material and preset really only makes sense if you're physically printing from Cura, which I would guess is not the norm given how many people are using non-Ultimaker printers, and printing from solutions like OctoPrint.

The way Cura behaves in this regard is a little odd. If you don't add a printing temperature to your preset, Cura will add a “M109 S0” to the start of your GCODE during slicing. Effectively telling your printer to set it's temperature to zero. You've now preheated your printer to the correct temperature for your material, hit print, and nothing happens since your printer is now waiting for the temperature to be set to zero.

I've been reliably using OctoPrint on a Pine64 since I wrote the original two parts (Part 1Part 2) of this series back in January. I was a bit behind on OctoPrint updates (running 1.3.2), and took the opportunity this weekend to upgrade to the latest stable version (1.3.4), and add in the custom action I've been meaning to create for remotely powering up my 3D printer.

I've been using a Ubiquiti Networks mPower-Mini to control power to my 3D printer since day one. In addition to providing remote on/off capabilities, these devices also allow you to track and trend power consumption and other metrics. Ubiquiti has unfortunately ended development of the mFi controller, but these devices are still manufactured for users willing to script their own interface to them. I've been working my way off of my existing mFi controller for this reason, and figured it was time to connect my mFi switch to an action inside of OctoPrint. This allows OctoPrint to issue the on/off commands directly to the outlet, without needing to login to the mFi controller, portal, or mobile app.

Picking up where Part 1 left off, it's not time to look at how to install and configure OctoPrint on the Pine 64, setup webcam streaming to OctoPrint, and make our first print!

I had a couple Pine64 boards sitting in a drawer, and decided it was finally time to replace that old Raspberry Pi running OctoPrint (err, OctoPi) for my 3D printer. The Raspberry Pi has served admirably, but it was definitely time for an upgrade, and a chance to improve a lot of my overall printing workflow.

Assembly Day 2 - The RigidBot Experience (Part 4)

Day 2 assembly really focused on the frame of the RigidBot, and the electronics. With the case for the main board installed on the bottom frame, the board itself is installed. During the Kickstarter campaign, all of the main boards had to be reworked due to an early design defect. There were multiple factories that performed the rework, and as you can see in the photos, I received a “red wire rework” board done by one of the Chinese factories.

Now that the campaign review is over, I want to put the challenges of actually getting the RigidBot behind me and focus on the printer itself. After much anticipation and persistent refreshing of my FedEx tracking screen the RigidBot finally arrived at the front door. The box certainly showed signs of having been bounced around a Chinese factory, crammed in a shipping container for a few weeks, then manhandled through the FedEx network, but cosmetic evidence aside things looked good.

Back in April 2013 I backed a Kickstarter project for the RigidBot 3D Printer. I’ve had many positive experiences on Kickstarter, and am a huge supporter of what Kickstarter represents—the idea that anyone sitting in their garage with an idea can create something great, and potentially define their future. That said, when one is throwing money into the pot on Kickstarter, you have to do a little due diligence to vet the campaign, product, deliverables, timeline, and the creators themselves.

I think it’s probably my due diligence in this area that has kept me in a position where I’ve had a very pleasant Kickstarter experience overall. Over 90% of the campaigns I’ve backed have been on-time, and many have delivered well beyond what is expected. There’s certainly campaigns out there that are horribly run, and much like buying stocks, there’s always a risk that you get nothing (or something that doesn’t work). This particular project had a lot going for it.

As someone who's always been into building things and understanding how things work, in recent years I've naturally been pulled towards the 3D printing space. The idea of being able to manufacture your own components (either replacement parts for things that have broken, or new things that you've designed) really gives you limitless possibilities.

My first exposure to 3D printing came in early 2013 when I was working on the design and first tests of a tracked robot I designed to take timelapse sequences with a DSLR camera. As I searched for appropriate pulleys for the drive mechanism (to no avail), I ended up commissioning those parts to be 3D printed—purpose built, one-off components, for a unique and specific need.