Some more 3D printing shenanigans: The Up!

chorl2 Comments

Scheduled plug: I’ve added a pile of new things to the Stuff for Sale page! Go check it out.

An exciting new thing came for me in the mail right after Maker Faire, and I think I’ve gotten finished playing with it enough to post.

Back in June, I wrote up the Democratic People’s Republic of Chibikart for Instructables and entered the Make It Real contest. It won one of the first prizes, which is an Up! Plus 3d printer, to add to my flock of 3D printers.

That was in July. I just got it a week ago, due to Instructable’s famed lack of shipping organization. That said, I was greeted with this in the shop last week:

Shiny. Let’s open it up!

I see the thing…

Very shiny (looks like glossy enamel) indeed. And orange, I guess because this was an Instructables-commissioned machine.

The Up is a pretty simple machine. It uses the ‘overhung arm’ architecture where the table is mounted on one moving axis and the head is mounted on another traveling, perpendicular axis. Now, I actually think this is the worst design for 3D printers because not only do you have issues stemming from workpiece acceleration (it’s moving), but the axis inertias are also mismatched.

Furthermore, the arm that sticks out is really flexible – it seems to be only mounted by one flap of sheet metal. It The X movement of the extruder is transmitted as vibration into the arm, and the end can resonate a fair amount – at least 3 or 4 mm of wobble at the end! Luckily the printing occurs very close to the arm’s support, so it seems to retain resolution accuracy. But still, it makes the machine design side of me cry a little. The new Up! Mini addresses this with a dual-rail axis design.

It also has a really really loud buzzer that makes it sound like an overly enthusiastic microwave oven whenever it starts, warms up, and begins/ends a print.

It also comes with a fairly extensive toolkit. Fairly typical 3d printer diddling tools like tweezers and a paint scraper are included, as are build platforms, mounting screws, and a nozzle wrench (but no replacement nozzle). I also got a pair of fabulously pink work gloves, but I’m not sure how they’re supposed to be used (are you supposed to grab the nozzle while hot?)

After I made a klein bottle as the printer’s first test, I let it run overnight on this compound of 5 cubes.

I’ll take a moment mention the UP! software. As far as I can tell, it’s closed source. It offers the usual array of tunable features – layer thickness, speed (just fast, medium, or fine), and infill (loose, dense, solid, hollow…), but only generates a square mesh (while Replicator can generate hexagonal meshes or just line scribble). It also slices way faster than ReplicatorG, but the user interface is a little strange with its button press sequence to do a common task like scaling or rotating, but that is a minor complaint.

What is REALLY nice about it, though, is how it generates the support lattice. This is the one place where I think it beats everything for intelligence, because alot of planning has to go into making a homogenous-material (i.e. not dissolvable or something) support that just falls away when done. If you’re a Stratasys printer, you can just puke support material everywhere because the intention is for said support to be dissolved away in the bubbling cauldron of lye. This is a very different, controlled kind of puking.

That entire cocoon for my cube thing came off in one piece, with absolutely no knifing or prying. Same deal with the “raft” layer. Contrast this with the amount of scraping and filing I have to do to the average Replicator(G) print and it seemed almost magical. I’m not sure how it is able to do this -it doesn’t seem to pause for a temperature change when moving between supports and part, so I think it must just be very careful extruder control to make sure the parts just barely come into contact.

It generates several different types of support – there’s the loose lattice that is used to build up the bulk of the support, then a very fine and nearly solid layer that is the one which makes contact with the part (which makes the near trivial breakaway even more amazing). There’s also a “cross hatch” like option which is used only for the loose layers.

Either way, seriously, what? I wouldn’t mind seeing a more robust support generation scheme for Replicator. Or, even better, maybe I should try hybridizing this guy with our Replicator 1 and make an Uplicator. I’d love to combine the high speed-capable gantry head of the Replicator with the Up’s slicing engine and controls.

There’s also one more thing I like, which isn’t Up-specific but I have not seen it until now: perfboard build plate. I am a definite fan of this. On that giant 4.25″ wide print, there was less than 1mm of lift on one corner of the hexagonal base. In ABS! As far as I can tell, the little holes in the perfboard cause the molten ABS to flow into them and hence achieve a mechanical interlock, way better than counting on the strong force interaction or something with a smooth tape. The Up came with 3 pieces of 2mm-space perfboard. I’m tempted to go buy a 6 x 8 panel from Radioshack and check out how it works with our Replicator.

I did a little more research into it and found that perfboard is now a common build surface, especially in conjunction with “ABS juice” that is made of ABS bits dissolved in acetone and painted on the platform.

The more you know…

After experimenting with the Up, I was determined to tune our Replicator to achieve similar qualities. Most of all, I was out to play with the support generation to see if I can achieve a less tenaciously integrated support lattice. I had been opposed to messing with before since technically it’s not “my” Replicator, but belongs to our research group, but I have literally not seen anyone else use it except me, so who’s gonna complain!?

I began by turning down the support flow rate ratio in Skeinforge way down. I had noticed before that the support material was almost as thick as my part lines, which seemed unnecessary. Next, I increased the density of the interface layers (which seems to drive the density of the support layers) so there was more ‘support resolution’. This did involve figuring out a better system so I could get the raft off the part easier (the denser interface layers appeared to want to stick to the part more than anything else). One more parameter I messed with was turning up the “support gap” ratio, which caused the lattice to be spaced further away – this was increased from its native 0.005 (meaning pretty much touching) to as far as 0.1.

I tested these settings by printing a few overhang dongles using full support and rafts, then when I thought I was at a good location, by test printing a difficult object which required full supports: this figurine on Thingiverse.

I think it turned out pretty damn great. Full disclosure: I tried this on the Up! and it got about 3/4 of the way up before the wiggling of the build plate caused the nozzle to bump the whole print off the machine. Oops. That’s what you get for being non-gantry, I guess.

Chunking off the support was pretty easy, but there were definitely lots of areas where I had to knife pretty hard. It looks like I’m the first person on Thingiverse to even try this print, too.

Additionally, one thing I noticed was that the long runs of very thin support lattice (seen in the first picture of the print) tended to warp and buckle much easier than a thin walled part would, probably because the flow rate is modified so much. On smaller prints it was okay, but I’ve definitely had support detatch from itself and curl up before. Once that happens (it seemed to happen at the base of the model), it is generally very hard for it to pick itself up again.

So I decided to try turning on the “crosshatch” option, which normally in RepG makes a pretty damn solid lattice that is utterly impossible to do anything with, but turning the flow rate down even further. The result is what I will call “point cloud” support. The string of plastic breaks between intersections (or leaves very very fine threads) and basically forms a coarse-, open cell, layer-by-layer deposited foam:

 

The “point cloud” is supported by the interaction of all those fine drool threads  and is remarkably solid if you push on it, but it falls away in huge chunks and the remainder is easier to scrape off. Still not Up! class, but a pretty awesome departure away from having to chisel your part out of its own pupa.

 

I next tried this method on the ultimate test: something I 3d scanned, so is not going to be remotely clean or easy anywhere.

 

The model in question is a Hatsune Miku mini-Nendoroid figure that I own. Now, if you know me, you know that just about the only thing I can be considered a ‘fan’ of is Miku and the Vocaloid media franchise and user community. It’s difficult to explain what it is without sounding like an internet startup guy, hipster and open-source advocate at the same time. In short it’s crowdsourced user-supported synthesized music you’ve never heard of.

Hey, when did I get a 3D scanner?!

It’s not mine, per se, but the IDC lab space has been getting some new toys since the last semester, partially in support of MAS.863, the renowned MIT Media Lab class that teaches fabrication and design skills (which Mechanical Engineering doesn’t have an equal to, by the way). This NextEngine triangulating laser scanner is one of them.

Since this was pretty much my first stab at 3D scanning, I neglected to take more than a few orientation scans (which meant the model had a ton of uncloseable holes in it) and then tried to save it at full resolution into an STL. The result was a 130 megabyte STL file that nothing could open or slice. I had to go back and greatly simplify the polygon count in order for ReplicatorG to even think about working with it.

While the STL just had too many gaps and errors for Replicator to generate a successful tool path (there’s some places that are just totally missing or filled with garbage), the “point cloud” support worked as intended. It looks really messy and disgusting on the outside, but the interior is a regular grid of very fine blobs and lines.

Since the whole point of this exercise is really just to get me a Miku figure clone, I tried it on the venerable Up. It handled the errorful STL wonderfully, though it pointed out to me where each and every one of the missing faces was. This was once again an overnight job…

Miku ended up being 4 discrete solids because of the holes in my model – the scanner couldn’t really capture the detail of the hair joint in the orientations I had it, so the point/mesh cleanup routine chopped them off. And no matter how removable the Up support is, it was still made out of the same ABS and so I had to cut part of her loop antenna structure off to remove the internal support, then reglue it back on.

Her legs are also… uhh, detachable?

But some hot glue fixes both problems.

I’m going to sacrifice this figure by supergluing the joints together so it can stay in one pose, long enough for me to scan it from every orientation. Then maybe I can get a higher resolution and fully one-shot printable model up on Thingiverse.

The bigger lesson here, though, is that I really like the “point cloud” support method. I’ve made so many changes to my Skeinforge settings that it’s not really worth trying to narrate them all here. So I’m just going to upload my slicing settings here (stuff the whole folder into your .replicatorg/sf_50_profiles directory and it should automatically recognize from within Skeinforge.

I’m actually kind of serious about trying an Uplicator hybrid. Pretty much all 3D printers are just a few steppers and a heater or two, so I don’t see much difficulty. They even sell the control board for the Up, but sell the CPU separately…for one hell of a sum. I wonder if that’s just an ATMega chip on a breakout board.

The only issue I see right now is that the Up homes differently than the Replicator – the former homes at “Z maximum” and the latter at Z minimum, necessitating different limit switch placement. In the mean time, Up!

but there’s a catch

With two competent hobby-class 3D printers sitting next to me, there’s something that has been a little forgotten which I will now finally decommission.

Poor Make-a-Bot.

The last time I turned this thing on was in late March some time. Ever since then, it’s been sitting quietly on a table, gathering MITERS grunge. The hardware, Makerbot’s Gen3 boards, and the extruder (a stepper chopped MK5), are generations behind. It was really never meant to be a 3D printer – too beefy and solid, but with my extra-stiff axes and much larger stepper motors I could still hold good resolution even at moderate (50-60mm/s) speeds. It’s really better off as a PCB router or very small mill.

Make-a-Bot isn’t being dismantled. Instead,

I’ve sold it to a hopefully loving new home that will turn it into something else awesome. Bye Make-a-Bot :(

The RageBridgeTwo Breeding Program Begins!

chorl4 Comments

I received the RagebridgeTwo boards literally the day before we left for Maker Faire NYC 2012! Here’s what the whole panels looks like!

That’s pretty. MyroPCB sent this panel to me sandwiched between two scraps of MDF which seems to have been the disposable bed of their PCB drills. I spent quite a while looking at the drill patterns from the other orders and wondering what they were (at least one seemed to be a user-generated breadboard…)

I’m fairly amazed with how well the thing turned out. After the designs posted last time, I made a few more minor layout and trace routing changes in order to be more compatible with Myro’s 2oz design rules. They seemed to want 8 mils trace/12 mils space for 2oz – which seems a little loose, as Advanced Circuits could go as low as 6/6 last time I checked. The trace widths weren’t a problem, but several places had problems with 12 mils spacing between elements.

I don’t think I did a very good job with the space thing, since that would have involved routing almost all the board over again (the gate drive area is a tight squeeze), but Myro ran them anyway and they seemed to all have etched properly.

I decided to make 2 boards out of the panel just to make sure that the routing worked. After all, no use in populating all 10 only to discover that I made a truly phenomenal routing derp (and I didn’t have parts for any more than 2 at that time anyway…)

Now with more FETs.

I’m going to try out several different FETs between these ten boards in order to gauge what the effect on continuous operating current without airflow is. I have the following types:

  • Infineon’s 034N06, 60v and 3.4mohm. These are pretty much the “worst” ones I have – I bought these originally when I was wanting to not blow up 5 dollars every time a FET goes (like I was with the IRFS3107s).
  • Infineon 017N06 60v, 1.7mohm. These are the current choice for Ragebridge and are in all the robots. Conduction losses halved from the 034s. These, along with the 034s, are both compatible with a 36v mode for these controllers. The only thing that limits the hardware to a certain voltage is the choice of FET and capacitor – for 36v operation, I’d want at least 60V FETs and 63v capacitors. 75v FETs would be even better, but they get pricy in low-resistance models.
  • IRF3004-7 type, 0.9mohm, 40V. These will be the best choice, I think, for the standard 24v type RB, but IRF is pricier than Infineon (whose nearest competition is the 011N04of 1.1mohm Rds-on and somewhat lower gate charge).

Once I prove the boards working or otherwise, I’d like to snag some of the new Infineon 010N06s that just came out. Basically, the lower the on-state resistance of the FET, the more current I can push through the controller, so long as the switching time is much shorter than the on-conduction time. Right now, with the 1.7mohm FETs, I can push approximately 30 amps continuous in still air while adhering to a 100 degree celsius junction temperature. If I wanted to edge closer to the maximum temperature of the junction, at 175C, then I can push about 40 amps. Again, this is with absolutely no airflow and no heatsinking effect from the board bus traces or large-gauge copper wiring. Any airflow at all would be sufficient to push the current rating up.

The two test boards are loaded one with 034N06 and the other with 017N06. I only have a limited quantity of the 60v types, so the majority of the boards will be limited to 24v nominal (~30v peak).

Fully populated but not yet programmed. I didn’t even leave myself an ISP header on this thing – that 6 pin header is an FTDI cable connector. So how am I supposed to program the blank ATMega chip? How will I even turn it into an Arduino?!

The answer, as usual, is provided by Hobbyking. Seemingly on a war path to be the next DIY electronics dealer, Hobbyking has recently been peddling everything from said Arduini to robot kits. Aided by the hobby multirotor craze (Yes! There are such things as crazy quadrotor guys just like there are crazy 3D printer guys and crazy electric rideables guys), HK now sells quite a few different flashing tools for microcontrollers. This cute spring-loaded programing socket is a steal at $20 – a similar device from a more “legit” manufacturer would certainly run you triple digits.

And as far as I can tell, it actually works, very well. The springs are stiff, so the pins dig into the chip legs tightly and allow some wiggle room too. Only downside, it seems, is that there’s no orientation guide (that I can tell), so it took me a minute of staring at my Eagle files to discern which orientation to use it in (Hint: Tight group of 3 pins faces away from the dot on the micro).

Seriously. Get that right now, especially if you think you might ever be flashing anything 32-TQFP shaped.

I used it in conjunction with an AVRISP mkII programmer, since I couldn’t get that damned “USBASP” thing to be recognized by my computer or to function at all. A 6 to 10 pin ISP crossover cable was made with some quick breadboarding wire to bridge the gap.

After the Arduino buttloader is loaded into flash, the rest of the program uploads are taken care of via FTDI cable.

I had some fun discovering that “Upload via Programmer” in Arduino means “Erase everything and upload just the compiled sketch” – I spent quite a while probing my RESET circuit to see why my FTDI communications weren’t working, and then it hit me that the damn thing wasn’t even blinking once at startup.

The only changes from the Ragebridge version 1 firmware were some pin definitions, since I had moved several connections around to better suit the chip orientation. Furthermore, the now fully-symmetric current sensor layout meant that one of the current control loops had to be inverted.

What I want to do next with the firmware is to make a “mix” mode for the two input channels, which means you don’t need a transmitter with onboard mixing (or to set it up) in order to use the the controller. Eventually I also want to make it take commands in the form of serial packets (over the FTDI TTL serial connector). However, it will not have any more complications than that – no fancy encoder inputs or selectable analog inputs or kitchen sink interfaces. Ragebridge was designed as a rebellion against those modern ‘universal’ ESCs anyway.

Right now, though, it’s just bone simple R/C servo PPM input.

The one thing which prevents a ‘MIX’ mode from being immediately useful on this board is the fact that I neglected to put any hardware selector on the board. One of the digital inputs can be tied to ground or 5V (e.g. with a PC jumper) to activate mixing, but I just.. forgot to put one on there. Instead, you’d need to solder a wire to a random place with GND, which isn’t very useful.

These, and other random layout shortcomings, will be addressed in a 3rd board revision.

In anticipation of possibly having to test 10 boards, I went ahead and designed myself a jig. Similar to a bed-of-nails tester, it just holds a bunch of 3.5mm bullet connectors in place to make all the important power connections (bed-of-bullets tester?!) so I don’t have to solder 8 wires every time.

Here are the connections completed. Inputs and outputs are both my standard 4mm bullet connector interface. A 3.5mm bullet just happens to squish enough to fit into the wire holes on the board, so…

Board #1 under test. Conclusion: it works.

Whoa, I assembled a board, totally untested in the middle of the process, and it works on the first try. That’s actually pretty damn new and exciting.

The second board had an interesting problem where one PWM out was seemingly underflowing repeatedly, very quickly. A bit of probing led me to discover that one of the current sensors had died (or was dead to begin with) and so was pegging at 5 volts. Constantly triggering the overcurrent procedure, it continually decremented the output PWM command, went past its valid ranges (+/- 255), then underflowed its signed int holder and kept decrementing from the top again. This caused the motor to occasionally freak out as the output command entered then exited the valid range.

The spazzing also damaged one side because it was while the board was hooked up to a non-regeneration-friendly power supply. I fixed it by replacing some gate drive components, but I guess now I know which board I am hanging onto!

The test motors were an EV Warrior and a derpy 24 volt scooter motor. Basically the test involved alot of slamming the motors back and forth (on a battery, of course) after validating controller functionality on a current-limited power supply. This was  to test if the controller was sensitive to pulsed current-induced noise, and if the smart current limiter was working.

Alright, time to start on the next set of boards. This is like 5 hours of solid work, and in the end, I totally ran out of parts! I’ll have to wait until the next Digikey order comes in before starting the soldering process again. First to run out were my gate drive zener diodes, and oddly enough, 1uF capacitors. I also ran out of ATMega chips and gate drivers.

The development process for this thing is starting to get reeeeally expensive. I have yet to total up the cost per board in this quantity, but the chances of me giving away free samples to alpha testers is very, very slim.

Once I get my refill orders in, I’ll populate and test the rest of these boards, and then set up the structure for an alpha testing run. I intend on releasing these “into the wild” as much as possible in order to find their limits and how people are going to mess up on using them. The guidelines below aren’t set in stone, but are what I have in mind as to what would make a good alpha tester:

  • You have a device, whether it be a robot or vehicle, that uses 2 DC motors in some way. Right now. Not “will in a few weeks or months”.
  • Your system runs 24 to 36v. Up to 48v is possible, but I would need to specially configure a board for it. HV testing is something I’m interested in doing.
  • Your system usually pulls 30 to 60 amps, and can live with 60 amps at most (This means some high-current systems like Magmotor-powered go-karts will experience constant-current mode for longer).