Si muove

OK, I was wrong about the noise. Or at least wrong about where it was coming from. Once I had an oscilloscope to look at the signals it became clear I had the pinout wrong. I was misreading the Sanguino breakout board, and once I moved the wires over one space everything started working wonderfully. (What does it say, by the way, when signal leakage across an air gap or a few megohms of resistance is sufficient to make the stepper driver respond…)

So as a test I clamped a stepper to the end of a piece of plywood hanging out in the general direction of the y axis, coupled the shaft to one of the surplus nylon lead screws, and ran it. It ran the platform back and forth  fine up to about 1600 steps/s, which is about 120 rpm, or about 50 mm/s.  I can probably tune that up some with lubricant and a little more voltage and current.

Quiltrap here we come. I’m not sure what I’m going to be extruding, but I’ve got a maximum build volume of 300x225x280mm.

For one brief shining moment…

It seemed possible that my solution could be reduced to “solder the bleeping pin, you moron!”. Of all the pins on the three stepper boards I assembled way back when, which solder joint had been omitted? The one connecting the direction line to the stepper-controller socket. So I soldered it. (And thank you, Adafruit Industries, for selling me a real soldering iron. So much easier with a real tip than with the Radio Shack version.)

Nothing doing. Didn’t make any change for the board I fixed. The other two boards worked exactly the same way. Looks like I’m going to have to get a scope. Grr.

Noise, Noise, Noise, Noise.

I am the Grinch, and my old reprap boards are WhoVille. This is nothing the rest of you don’t know already, but gosh the old connection system is a mess. I’m trying to get the old electronics working so that a) maybe I can actually make the original quiltrap with its huge build space and b) I can check out some surplus stepper motors without letting any more magic smoke out of the boards on my cupcake.

Anyway, the first time I tried this a bunch of lights flashed, but only when I was probing the breakout-shield contacts with my multimeter to see if anything was happening. This time the same thing, only I discovered I don’t have to have the other probe on the ground terminal, I just have to be holding a probe in my hand and touching the step contact. If I press hard the sound of the stepper goes from an ugly rattling noise to a smooth whine, and it turns much faster. Hmm.

Wikipedia says the human body has a capacitance of about 22 picofarads, so I guess that’s about the amount of decoupling I’m going to have to throw on to get rid of all the electrical noise. I’m also going to shorten the cables between the sanguino and the stepper boards something fierce. And maybe even consider — since I’m working in a basement — attaching an honest-to-goodness ground wire to the whole thing.

After that, it will be time to see if I can get the Sanguino to run something other than the stepper-test program I uploaded last year, which still seems to be running whenever it starts up.

My First Thing

It’s even potentially useful. Limited application to be sure, but if you want something like that, that’s what you want.  I have a few ideas about working around the skeinforge no-fill issue, but none of them are pretty.

I also learned a certain amount about designing simple stuff for cupcake. You need parameters to adjust anything that’s supposed to be an exact fit to outside stuff. And where a “normal” design would align things to the center of the main block, a design for extruder is much easier with alignment to one edge so you don’t need support. Also, I keep making stuff too big.

Associativity in Openscad

I’m probably missing something, and it’s probably about creating modules. Unions and differences are kicking my butt.

I was trying to create an annulus (the difference between two cylinders, like a donut or a tire) and then take only a section of that, so that I’d have a piece that was curved along one axis and straight along the other. Then I wanted to use that piece to take a bite out of a rectangle (so, for instance, C’s head thingy could have a smiling mouth).

No can do. Try to take a difference where one of the nodes is itself a difference and (as far as I could tell) nothing happens. I had to make a union and move one of the cylinders out of the difference and slice its edges off all over again. I’m sure there’s a rule for how you decompose and recompose stuff like this, but oy. If it’s by making modules somebody tell me (I’ve already sketched out the math for annular sections made by differencing cones and then cutting off rectangles to clip the parts you don’t want), or if I have to go learn CSG properly I think I might try and build a set of openscad bindings that will do the ugly stuff automagically.

On the other hand, the last couple hours of noodling show that it is possible to get the shape I want, just annoying.

 

(Oh, yeah, and I’ve been printing some calibration cubes and gosh. Not even close.)

This is what happens when you let a 6-year-old drive openscad

Yes, I know, my skeinforge settings need work. I think I’m extruding too much plastic way too hot (the thermocouple never gets below 210C), and probably with too small a layer height. The raft also sticks to the back of the object (as it has with a bunch of other prints) and my “tower” setting is way optimistic. Any other obvious mistakes I’m missing?

 

On the other hand, a 6-year-old knows none of these things, only that he helped sketch something and then 20 minutes later was dropping it in a cup of water to see whether it floats. And that the original design can be tweaked and improved pretty much endlessly until it looks like what’s in his head.

I think this is potentially(!) as big a deal for teaching kids as Logo was — C got the idea that you could make things out of “cubes” and spheres and “cylinders” pretty quickly, and he was even the one who suggested cutting a rectangle out of the big block to make the mouth. And of course we put things in the wrong places to start with, so the “translate” function was pretty obvious as well.

And he gets something to keep and play with that he can enjoy even when he’s away from the computer.

Okay, now it works

I have a mug. I have a couple of really bad lego blocks, I have a mostly acceptable half-cube and small tower.

The tweaking will be endless. Hurrah!

 

Oh, yeah, and I have to install sun java so the whole thing doesn’t crash every 20 minutes or so.

It’s about the permissions, stupid

Grr.  Apparently what you do when talking to a board to upload a sketch through the arduino IDE is not what you do when talking to the same board to replace its firmware with Replicator G. One needs root privs, the other doesn’t. Guess which.

After having frotzed the firmware on the extruder board and being completely unable to replace it, I read lots of discussions about failure to upload firmware and and when to push the reset button and corrupted bootloaders, so I finally got the idea that I would reburn the bootloader and thus start with a completely clean slate for the new extruder firmware. Ordered a USBTiny and a new soldering iron (anyone want a perfectly fine radio shack model that just won’t do small stuff?) and stopped just short of another arduino and a color touchscreen. Assembled the USBTiny, plugged it into the right places, told the arduino IDE to reburn me a bootloader, nada. (Well not quite nada, but an error message that even Google hadn’t heard about.) In my searches on problems with USBTiny and avrdude I came across a bunch of stuff about permissions and needing to run as root and exceptions rules, and figured “What the heck.”

Pause for a couple of days while I find out that the Ubuntu on my new machine doesn’t like things to run as root, and especially that there’s no good way to simply double-click on the arduino or replicator-g shell script and make everything happen as it should. But eventually close enough — I can sudo and type the annoyingly long pathname, or install a weird nautilus script that freaks me out by opening a new copy of the enclosing folder before — yeah — running under either sudo or gksudo depending on which the two lines of monkey-copied text tells it to.

I click through the upload sequence just the same as the previous four thousand failed times, and now it works. My extruder firmware is back, the thermocouple is reporting that it’s too damn hot in the basement even when the resistors are off, and maybe tonight or tomorrow I will have enough energy to actually try and print something.

Is there a place where I should have noticed the permissions issue way back when?

Learn something every week

Should be every day, but I’m getting old and slow. Apparently the reason I can’t unfrob my extruder controller is that certain communications between computer and board are privileged, and I’m not running as root. And running stuff as root from the GUI in Ubuntu is not as simple as it might be. I might be able to make this work tomorrow…

Oh, and love yez though I do, thanks for dashing my expectations, v2 folks. I got all the way through installing git, gcc-avr, scons and so forth, and puzzling out the platform syntax, only to find that the extruder controller is “not yet supported”. I could have told you that…

When worlds collide

When I started building a 3D printer, I installed a nice big 400GB SATA disk to hold all the software I would need and all the design files I would be downloading and creating. And in a fit of originality I named it “reprap”. So my copy of Replicator-G lives at /media/reprap/replicatorg-0024.

Like several dozen (at least) other people I discovered that Replicator-G doesn’t talk to my extruder controller when it comes to uploading firmware, but the regular Arduino IDE uploads files just fine. So all I have to do is upload the firmware with arduino.  Oops, where are the files? Good question. They’re not in any of the directories visible under /media/reprap/replicatorg-0024, that’s for sure

After a couple of weeks of occasional searching of blogs and forums, I find out what I would have known if I’d just read the Replicator-G configuration files more thoroughly and puzzled out enough to understand what I was reading. The firmware files live in /home/username/.replicatorg/firmware, a hidden folder in my home directory. All I have to do is open a shell and cd to it, or tell my file browser to show hidden files and folders, and there it is on a completely different disk from the rest of the Replicator-G software. Well of course. Why didn’t I think of that?

This location is not nearly as senseless as it might seem. But it does highlight the problems people face doing cross-platform software across different operating systems and different kinds of machine with different usage styles. Back in the days when *n*x machines were all multi-user beasts of one kind or another, it made huge amounts of sense for software to live in one place (/bin, /sbin, /usr and so forth) and personal configurations to live in each user’s home directory. And it made sense for those files (yeah, back then they were just files, not entire sprawling trees of subdirectory structure) to be hidden, because most of the time they were none of the users’ business, and you didn’t want them cluttering up valuable screen space in directory listings.

But now times have changed. Most *n*x machines are decidedly single-user, we no longer worry about screen real estate, and most applications have some nice global place where they can put files that pretty much everybody is going to use. So why the arcana?

Well, for one thing, a lot of the machines that control 3D printers might just be multi-user. And if you have a bunch of people doing experimentation, you really want all their different versions of the firmware to live in different places. For another, if you’re going to run on *n*x, windows and macos (yeah, I know) where else would you put the files? On a mac it would be somewhere under /Library or ~/Library, under *n*x it would be in /usr or /usr/local or /var or /etc, and under windows I how no idea whatsoever. And you’d have to figure out the permissions. A home directory seems as safe a place as any.

So maybe I should go back and upload the firmware now that I know where it is. The new motor arrived a while back and feels so much better than than the old one.