The dirty little secret in the world of 3D printing is that things go wrong (a lot). This week’s problem to solve is the frequent cross-threading of the rolls of filament itself. Filament manufacturers don’t seem to understand the requirements necessary for doing this right so it’s up to the rest of us to fix the problem ourselves.
Each time cross-threading occurs during a print job, you lose the entire print since the feeding of that filament just stops. In this photo, the printer has actually lifted the entire holder assembly off the workbench:
To deal with this problem, I decided to re-invent the spool holder itself by changing the inner topology from a rectangular shape to parabolic. It now delivers filament in a straighter path to the filament sensor block on the printer, minimizing cross-threading.
The reusable spool guide design incorporates eight individual parts which attach together using standard aluminum hex head bolts.
You might be wondering why you’d like to do such a thing. One of the best reasons I could think of would be to print different colors on the same part. In this part example displayed, black filament is used from layers one through seventeen and white is used from layers eighteen and up. The result looks quite professional even if this is using the lowest quality setting on my printer and it took less than twenty minutes to finish.
Saving an aborted print
Sometimes things go wrong. In the example below, my (costly) carbon fiber—infused filament spool ran out during the print job, noting that the printer arrived with a faulty run-out switch. For most people, they would just start over on such a part, wasting the plastic and the hours spent and begin again.
Fortunately, you can now chop your original GCODE file to just print the missing top to save the day (and the part, of course).
For years, if I needed to write a computer program, I’d have used one of the following: C, C++ or C#. Those have been the mainstays of programmers who needed an executable program for at least the two decades. Today, though, I’ve just written my first executable in a new language that’s surprisingly easy to work with.
The Go language is like the new kid on the block of compilers. Like the ones mentioned before, it will take text and convert it into instructions the computer can do.
Probably the best thing about the Go language is that it’s entirely open-sourced. If you wanted to work on the compiler itself, you could do so.
The program I’ve just written is technically called a Command Line Interface (CLI) program and will display technical details inside the selected GCODE file for a 3D print job.
Still designing/printing parts here in plastic from Autodesk Fusion 360, Cura and the Robo C2 printer. It’s amazing how long it can take sometimes to print. This particular part printed in just over eighteen hours but an earlier (high-quality) version suggested that it would have taken slightly over four days.
I’ve been having problems with a particular spool of filament from Shaxon. Given that it’s infused with carbon fiber, it has a tendency to want to stick to itself on the spool. So I’ve lost about three print jobs so far from a variety of nonsense related to the filament snagging itself as seen here.
This then results in the loss of filament to the extruder and the print job continues, going through the motions of printing but without plastic. To fix this, I’ve repurposed the base of my rock polisher to hold the spool and locking it in place with a coat hanger for the moment. When the filament tries to snag itself, the entire rig seems to work out with respect to deploying without accidents.
If you’d like to see what it looks like to 3D print a part like this, here’s a link to the video I created (using that new camera from an earlier post).
Oh, the fun. After a few fails, I managed to print out several C-shaped clamps in carbon fiber—infused PLA, finally getting the temperature right. I then spent several more hours in Autodesk Fusion 360 to further tweak/finalize the bottom of the chassis for the Raspberry Pi 3 supercomputer and sent that off for a 56-hour print job. Whoa.
Four of these clamps then were employed during last night’s printout while it was still going.
Unfortunately, the pause feature that I’d asked for in the slicing software went rogue upon resume and tried to bury the extruder into the plastic, forcing me to abort at 4am this morning. <_<
At least there’s much less part curling at the base versus last time. So I think I’ll redesign the clamps to have an even lower top profile and clamp right after the first four layers of the raft are down.
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…
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.
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.
I just got in the decidedly-cute DS203Mini DSO (digital storage oscilloscope), weighing in at a mere 80 grams. We can reasonably guess from MiniDSO.com’s website that English is a second language for them. From what I understand, this is an open-source project so it will be fun to see what I can do with this.
From what I’m reading in an online PDF, you can tether this to a PC and it appears as a USB drive, allowing you to make some modifications to the system itself. There appear to be examples for updating the splash screen logo and downloading/updating the application itself. Since this is likely some sort of Linux as the operating system then that will mean that I might be able to hack apart the update to find out what’s inside.
Looks like there are six adjustable potentiometers “under the hood” to allow you to calibrate it for accuracy. Most full-sized scopes have this feature but usually only about two of these adjustments, to be honest.
It was fully assembled in the box although the online PDF suggests that there was a time when the customer was asked to fully put it together. This one included two probes (1X, 10X) which is pretty generous given that they can be as much as $30 each. It includes a small hex wrench for opening the back (access to those potentiometers). And finally, there was a tri-fold card with the barest of instructions possible. Here’s an example of a third of the instructions:
Turn on the power, enter the main page of the oscilloscope. Place in the standard signal (e.g. square wave 1 KHz, Vpp = 5V), insert X1 probe’s MCX end to CH A or CH B, and the probe to “WAVE OUT”. Check if the measurement value and the standard value are equal, calibrate if different.
Okay, I know enough about oscilloscopes to know what they mean here. I’ll translate this into English-geek for you:
Connect the X1 probe to the CH A connection, power on the oscilloscope and wait for the main screen to appear. Remove the probe’s cover to reveal the bare tip, putting this into the center of the “WAVE OUT” port. Press Key 4 until the side menu is selected then use NAV 2 to select V1 from the options. Use NAV 1 to adjust the horizontal line until it coincides with the top part of the square wave, noting the voltage—as now measured—at the bottom of the screen. If this voltage is different than the reference 5.0V from the signal generator, then calibrate the meter by following these steps…
At least that is the standard routine on a full-sized oscilloscope. I guess what I’m trying to say here is that the online PDF and tri-card documentation are pretty laughable and aren’t enough for the average person to learn how to use it.
The menu is pretty difficult so far. It’s clear that NAV A and B are used in selecting different values and moving from one place to another. K4 appears to move between the top set of menus to those down the right side of the screen.
After two full evenings playing with the interface, I’m beginning to understand some of the strange logic. Some of the hidden functionality is found when you press down on either the NAV A or NAV B sliders. It’s lost on the average person that these left/right sort of controls actually can be pressed as well. This opens up the missing features which were formerly lost on me.
So now, I can put an output wave on the screen (CH A–inserted probe to WAVE OUT), adjust the signal to a square wave of 20 microseconds in width, add a single reference voltage V1, hide V2 (and Channels B/C/D), adjust the T1 and T2 reference lines to match up to the waveform’s leading/trailing edges and then reference the delta at the bottom of the screen. Given the complexity of this as compared to the absence of a working manual, I’d call that rocket science.
The next step will be to attempt to calibrate it with a known good 5V power supply which I’ve just adjusted, having measured that with a good-quality multimeter.
I’m torn between moving ahead now with my own work and writing a useful how-to manual for this oscilloscope. It’s a shame that someone’s not written a good tutorial yet for this.
Cool stuff, indeed. Out-of-the-box, it looks like you publish your Electron-based app like you would anything on github:
git clone https://github.com/Somebody/Repository.git
But there’s also a way of downloading OS-specific images and then adding your own app into this subdirectory structure. The result is a stand-alone EXE and folderset which reasonably looks like a drop-in replacement for something you normally would build locally using Microsoft Visual Studio perhaps. In this version though, you’d run Electron.exe but there are instructions on their website for renaming your application, updating the icon’s, etc.
I’ve just used it today to build a basic music player. I wouldn’t say that the layout is as responsive as a typical mobile app’s ability to move content but I did tweak things so that it can squash down to a mini-player and it stills looks great.
This allows you to build cross-platform desktop apps in much the same way that you’d use Adobe PhoneGap, say, to build for mobile apps.
So far, it seems to be well-behaved.
If you don’t want others to easily see your code, there’s a step where you can use asar to zip-up everything into a tidy package.
I didn’t have to digitally-sign anything like you might have to for a Windows 10 application or for OS X, say.
For people who have git and npm, the install is as easy as anything you’ve seen in the open-source space and a familiar workflow.
Currently, I don’t see any support for mobile platforms.
The complete foldedset comes in a 216MB which strikes me as a little big for what it’s doing. The app itself for the music player weighs in at 84MB of this so the remainder is everything that Electron is doing to present all this.
You would need to setup three different build sites to maintain a specific download for your own app. (It’s not like PhoneGap in which you just submit the common code and Adobe builds it in the cloud.)
Given that you’re not digitally-signing your code, you might have to talk your users through the hurdles of having the user “trust” the content within their particular OS.
This might be so popular soon that none of us can really afford to just use Electron.exe by default to serve up our app; we’ll need to rename it before publishing, in other words.
I can see myself wanting to really learn this one deeply. It has a lot of potential for delivering a more native-app experience for users.