Erik's Blog: Discussing IT, personal fabrication and a new and better world

From the RepRap blog: Progress is being made by Rhys Jones to have the Replicating Rapid prototyper make more of the parts that you need to make another one. I think that this is exciting!




Interesting to note is that it uses regular solder.

I passed my last exam I have to do for my masters degree! I 'only' need to finish an internship and write my thesis... and then I'll be Master of Science, in addition to master of disaster (frying RepRap parts) and master of distraction (taking on too much web development work).

Debugging sucks...
I'm (re)building my machine, and one thing I'm missing is transparency. We're adding layers to keep complexity manageable, but inevitably some transparency is getting lost along the way. There are several interfaces where things can go wrong, so in the scenario where a motor doesn't move:

1 it could be the host software,
2 the cable to the arduino,
3 the arduino hardware,
4 the arduino firmware,
5 the arduino output I/O to slave board,
6 the slave board cable,
7 the slave board,
8 the cable from slave board to motor.
9 The motor itself.

I usually end up testing 1 trough 5 when I find out that I forgot to reattach the motor (8). Or worse, I test 1 trough 9 and realize I hadn't assessed 1 correctly. I admit that I'm not too organized and this gets me into trouble and blowing components.

We should give the RepRap a voice!

About stepper motors making sounds (inspiration from Zach). It would be VERY useful to have the motor produce audible feedback that will not result in motion, but sound, originating from the component of which you want to highlight connectivity. This way you can instantly check connectivity (at startup) of each of the motors (1 through 9). You will also more quickly notice the implications of changing something, since you don't need to actively test everything with a multimeter, but just passively listen to your machine to hear how it's feeling. This way you still remember what you've done to break something, since it's not an hour ago and you're now involved in another debugging. You know when you hurt, it as soon as you do, and more importantly, you know when it's happy to print for you

When the firmware starts, you don't want to move all the motors, it might be in the middle of an interrupted job. But you do want to hear X = OK, Y = OK, Z = OK, extruder motor = OK. Why not hear it through audible beeps of varying frequentions. You will need to hear 3 distinct tones, and you'll know the cartesian bot is good to go. For bigger and more complex systems the usefulness of this principle will increase.

The cool thing about this 'feedback' is that it is reliable. If a motor is connected but some test-measurement isn't, or it doesn't reach the GUI (lost in some layer), you stop relying on this as an indicator. But for these motors producing sound, it is accurate.

So, reliable and fast assessments of the status of components of a machine are highly desirable properties, especially for prototypes under development!

A sound for reaching the origin (reference position (X,Y,Z) = (0,0,0)) would also be desirable.

Any other status info that would be important to you?

We all know about complexity: if you build a system at your level of competence, debugging it will be above beyond your problem solving capacity. In other words:

The significant problems we have cannot be solved at the same level of thinking with which we created them.

--Albert Einstein