LesterCHall

Introduction

Hi let's get straight to the current point of interest which is the notion of using audio and images to transmit 3d printing models. The idea, or at least my conception of it, originates from my "Hot Rod 3D Printer" project which I will discuss later and the story also touches on a distributed Arduino and driver architecture using a sort of audio machine code... but let's talk about the files first. Here goes nothing!

A Short Story to Ilustrate the Concept

Imagine you are an 11 year old kid. You wake up on Saturday morning - YaY it's Saturday! So you get yourself a bowl of cereal and turn on the cartoons. It's not your favorite cartoon yet so you look at the cereal box and on the back is a giant QR code. The box "prize" is a T-Rex action figure but you know it's not IN the box anymore, it's ON the box now. You're old enough to operate the family 3D printer next to the TV so you put the QR code image in front of the printer's camera and press scan. A T-Rex model appears on the screen so you press the print button and watch as the printer makes your T-Rex model for you.

Then you go back to your cartoons, T-Rex in hand, and your favorite cartoon is just beginning. You see that the action figure in the cartoon is a new Marvel Comics character called Eyesore the All Seeing. You like the model, so you press the Audio Receive button on the 3D printer and when the TV cartoon beeps and blips it's audio encoded STL file out the speakers, your 3D printer recognizes the communication and learns the model. You see a giant eyeball with smaller eyeballs on tentacles on the screen and you like that model so again you press the print button and watch as the printer makes your Eyesore the All Seeing model for you.

This Saturday morning fantasy has been brought to you by the Image and Audio encoding of STL files which together enable almost any medium of transmission to send a 3D printable model file. This includes magazines, product labels, junk mail, textbooks, posters, television, radio, telephone, mp3, clothing, jewelry, keys, or really anything that is capable of displaying or playing sufficient information to transmit a model file.

Fast forward to Monday morning in a less developed part of the world such as the more remote areas of Africa or Asia or - well, any place that is remote - and there may only be cell phone technology in common use - and what we now call "dumb" phones at that without internet access or app running capability. All you can do is make calls, send and receive texts, and exchange audio files - ah there's the ticket! Since you can store and transmit audio files, you can also store and transmit 3D models for viewing, modifying, and printing either at the local community data center or for transmitting to anywhere in the world by telephone. This opens up the possibility of the third world suddenly becoming capable of participating in the world economy by creating and sharing 3D model files. Many people feel that the single most effective technique for eliminating starvation and substandard living conditions that plague the bottom billion of this planet is to enable them to participate in the world economy. In fact, our Saturday morning cereal munching cartoon fan gets home from school on Monday and finds a 3D model file made with his African friend's "dumb" phone cam and some cloud based scanner tech using audio transmission techniques. It's a model of a design that his friend has imagined and the two are collaborating together to create.

So maybe this fiction is a bit of exaggeration, however I do think it is realistic to imagine a significant impact in the transmission and usage of 3D tech if we only define and implement systems based on audio and image encoding of 3D model files. I am developing such a system for running my Hot Rod 3D Printer which is driven by an audio signal from my Mac. At the moment only the X-axis stepper is being controlled, but within about a week or hopefully two weeks at the most I will have the whole thing working (I'm waiting all this week for parts to ship, sigh). more on the Hot Rod 3D printer later, just suffice to realize that it was this audio encoding of my printer's control that led to the notably different notion of audio and image encoding of STL files. Anyway, there are many ways to encode the files and I can make some suggestions but really it falls on the experts in this sort of field to define the file formats. I just realized it was out of my hands and had significant potential so I went to #reprap with it and they led me here. So there you go.

Distributed vs Centralized 3D Printer Architecture (with discussion of audio control)

The conventional Arduino / RAMPS board architecture of a 3D printer is a centralized design because there is one single location for the processing and electrical driving circuitry and all the steppers, heaters, thermistors, and limit switches get connected to that central control core. This system works and it has it's own set of advantages and disadvantages, yet it is not the only way to create a 3D printer. In the process of hot-rodding my 3D printer, I stripped it down to the wires, rods, and motors ("it" being a ROBO3D R1 model) with the intention of using a few of my favorite microprocessor chips, the ATtiny85, to replace the larger more expensive centralized Arduino board. Then one morning I looked at the mess of wires strewn all over the printer carcass and had an epiphany, a light bulb over the head going blinky blinky moment, in which I saw the whole thing as a distributed system. Here's how it works:

I plan to use seven ATtiny85 processsors on seven circuit boards to drive the five steppers and two heaters of the printer. At this time I have constructed two test circuits which are both capable of driving the X-axis stepper so that it moves the extruder carriage left and right across the print bed. The first circuit is a stand-alone device, just turn it on and the print head goes back and forth over and over and it is based on the Arduino Uno R3 board with a protoboard shield just because a friend gave it to me and i had it lying around. Its many pins (I used 8 of them) permitted me individual control of each BJT drive transistor for experimentation purposes. The second circuit operates under audio control from my Mac which is running the ChucK programming language. I coded up a very simple pulse width modulated oscillator for the job and it sends out a 100 Hz square wave with a pulse width that encodes the desired position that the ATtiny85 is commanded to reach. The ATtiny85 is capable of measuring both the high and the low portions of the oscillation as long as the oscillation lasts for two or three cycles or more. So I give it 10 cycles then shut it off and emit silence for another 44 seconds. The ATtiny85 knows where it is on the X axis and now knows where it should go, so it counts out as many steps as it takes to get there then just stops. Then ChucK sends out the reverse command and the carriage moves back to it's starting point. this continues until stopped.

So that's the control mechanism but it needs a bit of upgrading. I want all of the axes: X, Y, Z-, Z+, and E (for Extruder), B (for Bed Heater), and F (for Filament Heater) to operate simultaneously at programmable rates. This is to give full control of the printer's capabilities to the software so that it becomes capable of doing wire print and geometric extrusions, music interpretation and so on. To accomplish this I plan to add a "GO" command and a "RATE" command so that the position and rate are transmitted to each ATtiny85 in sequence, then a GO command tells them all to execute at once.

Now having discussed the audio encoding I should get back to the main point of this section which is the differences between the distributed and the centralized systems. I don't know about mathematical proofs or definitions, but I would think that these two are "duals" of each other, or different sides of the same coin. As such they share some characteristics and vary in a dualistic way in others. For example, a shared characteristic is that both consume electrical power and probably a very similar amount. The difference in power dissipation, however is that the centralized system generates heat in a control cabinet and must be cooled with a venting fan, while the distributed system's heat is located in part within the build chamber (or can be) so that the heat is used to warm up the chamber and is therefore recycled. Also different is that the distributed system is at least in part subjected to the build chamber's temperature which may be quite warm to the point of being a drawback. But these are subtle differences.

More significant is cost. An Arduino capable of interpreting G-Code and running a RAMPS board will cost a good $30 USD or more, and the RAMPS board is easily $15 USD at current prices or more depending on life cycle of the board revision, so we're talking about $45 USD or thereabouts for the electronics of the printer. The ATtiny85 in quantity 10 has a price of $1.75 USD and the eight transistors per stepper channel are $0.12 USD each in quantity 10, of which you need 40 for a total of $4.80, plus two power transistors for the heaters at $0.50 USD each and a handful of resistors at $0.01 USD each max, you're talking about a total parts cost of $23.00 plus circuit boards. Boards are cheap in quantity so the total cost of the distributed system's electronics is $30.00 That's only 2/3 the cost of the centralized system and I believe that with integration and volume pricing, lower costs are possible. Also lowering the cost is the fact that the wiring becomes greatly simplified as discussed in the next paragraph.

Wiring, right... taking a look at the wires coming from my extruder carriage is a bit of a sobering experience. It requires such a snake of control wires that my printer came with a black plastic corrugated sheath to cover the mess of wires! By locating the control system for these wires on the carriage, only three or at most four wires are required; Power, Ground, and control are needed, plus it may be desirable to report extruder temperature back to the computer on a receive audio channel, so a fourth wire may be necessary. Compare that to the following list: 2 thick wires for the heater, two wires for the thermistor, two wires for each of two fans, and four wires in a thick insulating sheath total a whopping 12 wires. That's got to have an effect on print quality because the snake of wires resists motion of the carriage. On my hot rodded 3D printer i plan to braid the colorful high temp hi current silicone coated stranded wire that i bought from adafruit for an attractive and flexible solution. In defense of the centralized system I should add that the additional mass of the circuitry on the carriage is a factor but compared to that snake, I'd take a braid and a board any day.

There is one more circuit board in the distributed system, and that is the star board where all the connections meet. I call it the star board because of the star ground that is used in such systems to prevent ground loops. Not only the ground, but also the power and the two signals must be located on this board, or will be in my design, so yeah star board is appropriate I guess. I half jokingly imagine the star board to be shaped like a Texas star (being a Texan at this stage of my life), where the five star points each hold a connector going to a location and the center goes to the power supply and to the audio jack. The star board may need an eighth ATtiny85 processor to combine the two thermistor signals into one return signal going into the mic input of the computer.

As a final note in favor of the distributed system, i'll note that each circuit board can have LEDs showing each of the key signals - most notably the stepper drive signals and also the limit switches plus thermal signals and possibly power. That way it's easy to do fault diagnosis by just watching the LEDs and getting used to their proper operating appearances. Plus it makes for a great light show that everyone will appreciate! Doing this on a centralized system adds more wires and boards and mounting fixtures and cost and complexity and ugh no thanks, I'll go with distributed for my hot rod printer, thank you very much!

Conclusion

Well I've been writing for a while and I'm getting tired plus I think I got most of the info into text form or at least the highlights of it. I propose that the community develop an image and an audio encoding of STL files. I also propose and am currently implementing a distributed "hot rod" approach to the 3D printer electronics featuring the mighty yet itty bitty ATtiny85 Arduino processor. Plus I propose more LEDs! We cannot have enough LEDs! Oh, and don't be afraid to deck out your printer with show-quality features like automotive paint and electric windows and doors, or whatever strikes your fancy. It's time to hot rod our printers!

Enjoy,

Les