palago tiles

Palago is a simple-enough game that’s like Go but hexagonal instead of a grid pattern. It includes 48 identical tiles with a light/dark theme. Players vie to create closed shapes in their selected color.

I decided to design and 3D print a set. I’ve got the first tile now and I like it. I managed to create in one version a beautiful tile which prints nicely in two colors (on a single extruder printer). Both colors are at the same height which was a challenge…

What was interesting about the design is trying to allow the bevelled nozzle on the printer enough close access to lower layers in order to print this in multiple jobs. The base white part prints as the first job and finishes at 4mm in height; the next two print jobs are in a second-color of filament like blue in this case and start at the 2.4mm height layer and continue from there.

Screen Shot 2019-09-15 at 3.22.41 PM

It was necessary to manually edit the 2nd/3rd print job’s content for the sake of safety and to disable bed autoleveling (which could have caused problems). I was excited and nervous to push the Print button in OctoPrint and wincing a little as it begin. These things either work or they can go spectacularly wrong. Fortunately, it worked perfectly, the tolerances were exact and it produced a great-looking Palago tile.

recycle, re-use, re-purpose – part ii

Continuing with the work to re-purpose a computer mouse as a filament movement detection device, I designed and printed some parts for this. The bottom part is perhaps 5mm in height from the spool itself and is reasonably a good distance to see changes.

I’ve edited the earlier Python script which originally detected the scroll wheel button; it’s now detecting movements of Y as if the mouse were being moved on a mousepad. It will only do this if I take the white assembly and move it around on a patterned surface, however.

To help the mouse detect movement better, I’ve tried using both grid paper and a polar version of same. I don’t love the feedback loop that’s going now. I’m sure there’s a better way to get this movement detected all the time, though.

IMG_0115

IMG_0116

IMG_0118

recycle, re-use, re-purpose

This week’s project involves dealing with filament-delivery problems on my 3D printer. Out of the box, the filament runout detection never worked. Frankly, it was a terrible design to begin with from the manufacturer and I’m convinced that someone at the factory just turned off that behavior anyway.

As a result of this, I’ve lost a few print jobs over the last year. In only two cases, I simply ran out of filament for large parts. In all the remaining cases, a number of problems contributed to the loss of filament delivery to the printed part:

  1. simple end-of-roll loss of filament
  2. spool sticking to manufacturer’s poorly-designed spool holder
  3. cross-threading of the filament on the roll
  4. hot-spooling the filament at the factory which resulted in filament which sticks together
  5. filament like carbon fiber—infused which likes to stick to itself
  6. old filament which is now brittle and breaks as a result
  7. overall poor design of the spool (boxy) shape itself, resulting in cross-threading
  8. overall poor design of the filament delivery path itself, resulting in too much force needed to extrude
  9. filament thickness quality issues as combined with PTFE feed tubing, resulting in stuck filament in the tube
  10. too-flexible filament as combined with any of the conditions above, resulting in filament notching at the bowden gear
  11. z-offset too close to the bed, resulting in hotend jamming
  12. poor first-layer adhesion, leading to a build-up of filament and ultimate hotend jamming

Now granted, the bowden drive for this printer is one of the beefiest NEMA 17 style of stepper motors I’ve seen. And yet the number of filament delivery—related problems is just too high to continue to ignore. So I’ve decided to finally deal with the issue rather than working around it.

Ideas & inventions

Remove the stock holder, add bearings to its replacement

I designed, printed and assembled a very good dual-spool filament delivery system which worked much better than the stock filament holder. I sometimes still use it.

DSC_0062

Dual runout switches

Perhaps six months ago, I designed, printed, sourced parts for and assembled a very good dual-spool filament runout detection block to replace the stock part. I have yet to install it since I’m not in love with the idea of the filament path beginning at the table level. Time has taught me that the spools need to be higher than the printer for this to be optimal. As designed, though, it works in principle to detect loss of filament from both spools.

DSC_0211

And yet, this entire concept does not directly address the problems associated with cross-linked filament. It only addresses the loss of filament as seen in a switch.

Parabolic spool guides and re-purposed monitor stand

Additionally, I designed, printed and assembled parabolic spool guides to better deliver filament (especially for hot-spooled or otherwise sticky filaments like carbon fiber). This I combined with a designed/re-purposed dual-monitor stand to move the spools above the printer rather than below.

SpoolHolderOverhead

SpoolHolderWithBracket

Remove the temperature gradient

First-layer adhesion was aided by adding a foam enclosure/door and a temperature-monitoring Raspberry Pi 3B to the inside (opposite the internal webcam). The latter helps to heat up the print volume area, keeping things from 90-100 degrees Fahrenheit.

foam

Remove the PTFE tubing

Filament diameter inconsistencies resulted in filament getting stuck in the PTFE tubing. I now rarely route the filament through the tubing, having removed the awkward bottom-to-top filament delivery path from earlier.

And finally, a filament movement detection mechanism

This weeks work then revolves around fixing the underlying problem. The solution isn’t filament runout detection. The more accurate problem and better solution is actually loss of filament movement and its detection.

When I began to think of solutions, in my head I was adding black/white encoder rings to the sides of the spools themselves. I would need to add those to all spools of course. I’d also need to design something which reads those as ones and zeroes.

I decided that a roller/follower which is turned by the spool is also a solution. I then envisioned writing drivers and creating a small circuit board for all this so that it could talk to Raspbian, the operating system which OctoPrint runs on.

Mouse to the rescue

Finally, it hit me that a standard computer mouse does this naturally. The older style of ball mouse has a follower which detects when the ball is moving. Even the newer style of mice still have a scroll wheel which is covered in rubber and would do nicely. In my imagination, the first iteration of this had the filament trapped against that rubber wheel. In today’s version, the wheel merely comes in contact with the side of the spool itself for the win.

As a bonus, the computer mouse already has the serial communication and Linux driver built-in. It was trivial to write a small Python script to detect scrolling events.

no mice will be harmed … in the making of this gadget.

The mouse should fit nicely and without any modifications to a 3D-printed holder. The serial connection goes to the Raspberry Pi and is then detected in an OctoPrint plugin. During a print job the scrolling events will be monitored; any loss of scrolling over the sampling period will then pause the job and alert the operator with a sound event.

rat on computer mouse

logistics for the black pearl lcd theme

I decided to add more to the earlier Black Pearl Conky theme for my 3D printer’s TFT screen. It turned out to be a lot easier to do since I’d just finished a new module for OctoPrint.

octo-client:  A node-based module for directly talking to OctoPrint to gather raw information.

octo-conky:  A Conky script for returning that information in a pleasing way.

The new information is there after the “Black Pearl v1.0.1” line where it pulls the version and temperature from the printer.

IMG_0037

black pearl

Since I’ve had the 3D printer for nine months now, I thought it was time for a facelift. I decided to re-theme it completely on the software side of things. The first step was to change out the web interface (stripping away all of Robo’s theme and modifications) and now I’ve replaced the LCD menu as well, which now looks like this:

Black-Pearl-Screencap

PrinterWithLCD

I created this design using Conky, a system monitor from the UNIX world. The theme was inspired by an earlier, larger desktop version of this by Ninquitassar but this was a total re-write.

I hope to now re-theme the web interface to match this styling and to then fork & recompile Conky itself to natively provide the details of the in-progress print job itself. It would be nice to have a feedback loop for the Amazon Echo Dot so that the voice controls will in some way alter the screen as an acknowledgement.

Repository

j.a.r.v.i.s. realized

If you remember from my earlier post, I wanted to build the cool AI interface from the Iron Man movie series: J.A.R.V.I.S., as voiced by Paul Bettany.

jarvis

Well, I’ve done it. I wrote up several intents in an Amazon Alexa Skill, created an Amazon Lambda function as the end-point, created a proxy in Node (which is served up by a Raspberry Pi Zero W single-board computer) to forward inbound Internet traffic and I’m now able to ask an Amazon Echo Dot how my printer is doing at home.

EchoDot

Remotely Control a Printer

For example, I can say:

Computer, ask Jarvis for my printer’s status.

…to which she will reply:

charming-pascal is ready and operational.

Now remember, I’m two miles away from home while I’m doing this and all of this still works.  I could ask:

Computer, ask Jarvis which file is selected.

…and she’ll say:

RC_microSD-clip.gcode is currently selected.

This is useful to know when I later code this up to remotely print a job as well. I can also ask:

Computer, ask Jarvis for the job status.

…and the reply might be:

charming-pascal is finished printing RC_microSD-clip.gcode

In the collection of skill intents, I now have the following:

  • Stop the print job
  • Start the print job
  • Pause the print job
  • Resume the print job
  • Ask for the print job status
  • Ask for the selected print job file
  • Ask for help
  • Open the Jarvis app

And I’ll need other intents to select a file to print, preheat the extruder and possibly other things yet unimagined.

I’ll definitely want to remotely see the output of the internal webcam inside the printer to make sure that it’s happy; sometimes print jobs go afoul for a variety of reasons.

Remote Power Control

In addition, I also purchased a TP-Link Smart Plug to control power to the printer. I now have an Alexa skill to turn the printer on and off remotely.

tp-link

Computer, turn on my 3D printer.

da plane

Obviously, I watched too much television growing up. Every week on Fantasy Island, Hervé Villachaize’s character would point to the sky and make this exclamation.

da-plane

In a 3D printer, it’s really important to start printing on a known, flat plane. And yet, many print beds aren’t made of something rigid like glass so bigger parts end up shaped like the print bed itself. Even small deviations can mess up a print. It’s a problem to be solved, actually.

OctoPrint

The software that’s running on my Robo C2 printer is a fork of the popular OctoPrint open-source software. What’s cool about this software is that it will allow you to write plugins to adjust the way it works.

GCODE

The language the printer listens to during the print job is called GCODE. Think of it as a list of common instructions that almost all 3D printers use now.

Autoleveling

One of the GCODE commands in question is G29 and this tells the printer to run through an autoleveling routine. In some cases, the printer’s extruder will actually touch the print bed in several locations. In others, the extruder assembly will use a light plus a photoresistor to hover above the bed and to gauge its height above it. Using either method, the printer can make a reasonable “map” of the print bed and mathematically create a virtual plane to represent it. If the print bed is a little lower on one side, this routine should allow the printer to compensate for that.

Only…, it doesn’t really work that great, to be honest. Someone deserves a round of applause for trying to fix the problem but honestly, a manual approach is possibly the better way to go here.

Although these printers have a built-in autoleveling feature, manually leveling the print bed is preferred by those who are more advanced at 3D printing.

The Problem

I’m currently now working to manually adjust my print bed so that it is perfectly level and an exact height from the extruder. In fact, I have two replaceable print beds for the same printer so both of them need to be perfectly level and exactly the same height all around. To complicate matters, I anticipate designing and creating a third print bed for this which is heated. And that one should also be perfectly level and the same height as the others. The final goal will be to easily and quickly swap print beds without the task of fussing with any settings.

So now, having created a number of GCODE files over the last four months, I really don’t feel like editing them to remove that unnecessary G29 command. Once you’ve manually leveled everything, an autolevel routine is not only overkill but it can cause problems to the print quality. I needed a way of programmatically switching off the command when seen.

The Solution

I’ve created an OctoPrint plugin which helps to solve this problem. Assuming that I no longer need autoleveling at the start of each job, the plugin tells the printer basically to ignore any G29 commands. I now don’t have to edit countless GCODE files or worry if someone sends me a file—the printer will dutifully ignore this command.

Github:  Toggle Autolevel plugin

 

time-lapse photograpy for the robo c2

I’ve upgraded the Robo C2 printer with a nifty Raspberry Pi NoIR camera so that it can take photos, stream video and do time-lapse photography of print jobs. It seems to work great so far and I look forward to putting it through its paces.

And to make this easier for others, I’ve created a documentation repository with step-by-step instructions for anyone else who wants to modify their original printer to do this, too.

Okay, so technically the printer had a glitch 1/3 of the way into printing this (huge) coin example, so I aborted as it started to go funky at some point… which you can’t tell here, tbh.

When printed part becomes modern art

don’t make me clamp you…

Trying to push the envelope in print volume on the Robo C2 printer, I’m finding that the part wants to curl on the bed (since the latter isn’t heated). Hmm…

curl

This is a common occurrence, I understand.  It’s due to the uneven temperatures of plastic on the bed versus the new (hot) layers of added plastic. To get a part this big, I actually had to lie to the software and to suggest that the printer has a bigger range than this. This sort of tweaking is commonplace.

Hairspraying the bed is a known gimmick for 3D printing, but as you can see, the painter’s tape is well-stuck to the part.  Instead, I’m thinking of 1) printing the raft at the bottom, 2) pausing the print at this point, 3) removing the bed, 4) applying clamps around the edges and finally, 5) resuming the print job.

Tool-Making 101

From my experience in a plastic manufacturing plant, I learned that if something doesn’t work:  modify it, build a helper tool or change the process somehow so that it does work. Here, I’m opting to build a set of clamps to assist in the 3D print process and to insert a pause into those instructions (“GCODE”) at the proper moment.

Half the battle, then, is designing and building a number of clamps.  To be useful, they should allow their placement at a variety of distances from the edges of the bed. They should hold throughout the job even if things are vibrating and moving around. They should never restrict bed movement. Since the print job goes for perhaps ten hours, they must not fail in any way if I’m not there to watch their performance.

The other half of the battle is to create something which modifies the GCODE instructions to place a pause at the right moment (as soon as the raft has been laid down). My guess is that this will look like an OctoPrint plugin. There probably already are a number of plugins which pause at a particular z, meaning that they will pause the print job when it comes to a particular vertical layer. I was thinking that I might invent a different approach somehow in this space but I’ll see what I can come up with. I like the concept of pause after raft, though, and would imagine that this would be useful enough to others.

This should save a lot of print jobs from curl, I hope. And that should translate into a lot of money saved in filament, as well as time.

clamps