Calibration

[Slatye]

But to do that you need some way of communicating with it. The easy approach would be a microcontroller on the serial port with a transistor to turn on/off the laser - except that this means you need a microcontroller, a circuit board, and a transistor. Since so few PCs now have serial ports, an FT232 might be necessary as well. That's at least an extra $10 on top of the original price, and realistically it'd be more like $20. You can skip the FT232 and talk to the microcontroller through the same audio channel that drives the mirrors, but that makes coding a bit of a challenge. In contrast, just pointing the laser away from the bath costs nothing.

[nka]

You got a point, didint think of that, since I'll add a Microcontroler myself if none is included.

[Slatye]

I'll probably do the same. I'd like to have a little board (possibly one of the STM32F3/F4 series) with a few fast ADCs that can read a print job file from a microSD card. Completely standalone, and way more flexible than it's possible to be when using only a couple of audio channels. It'll probably cost $50 in small quantities, but that's absolutely worthwhile if it gives the printer much better capabilities.

Once you do this there are lots of options. You can turn the laser off when it's not needed. You can stick a servo on the water valve to automatically adjust the Z-axis rate, and a reasonably high-precision water level sensor to continually re-calibrate the Z axis. Someone will probably figure out how to make it swap resins automatically, although at this stage I can't see an easy way to do that. I'd pay $100 extra for that, and it'd still be the cheapest 3D printer around.

[stringray]

But to do that you need some way of communicating with it. The easy approach would be a microcontroller on the serial port with a transistor to turn on/off the laser - except that this means you need a microcontroller, a circuit board, and a transistor.

The original goal of the Peachy was to not have any of these hardware requirements. Also not sure it is easy to get the analog speaker output to communicate to a micro controller and issuing commands, feedback would also be an issue as the mic input is already used.
It may be possible to turn off the laser by not having any sound

In contrast, just pointing the laser away from the bath costs nothing.

Pointing the laser to a "home" may not work
1. you would be hardening the resin along the path the laser moves from the object to "home". There would be a web of harden resin spanning the area between the object and "home"
2. the object file to sound file convert software will now need to be far more intelligent as it will now need to know the spare time it needs to kill at "home" for each print layer. This is akin to software that automatically adds supports structures under print objects with overhangs for extrusion printers.

[Slatye]

The original goal of the Peachy was to not have any of these hardware requirements. Also not sure it is easy to get the analog speaker output to communicate to a micro controller and issuing commands, feedback would also be an issue as the mic input is already used.

Yes, that's why it seems unlikely that the stock setup would include a microcontroller. I suspect that many people will add one to their Peachy later, but it won't be standard equipment.

As I said above, getting the microcontroller to communicate through audio channels would be a tricky bit of coding. I'm sure that someone has figured out how to bit-bang serial data through a soundcard, but it's not going to be pretty. Much easier to just go through serial/USB.

It may be possible to turn off the laser by not having any sound

I may be wrong, but I suspect that this would need more hardware.

The current setup, as far as I know, is that the laser is always powered and the mirrors are driven from the audio channels. Even turning the laser on and off is going to require a transistor and a little circuit board, increasing cost.

The simplest way I can think of to actually turn off the laser when both channels are off would be two comparators and a mux, and possibly two low-pass filters too. It's a fairly complicated circuit and tuning it right might take quite a while.

Pointing the laser to a "home" may not work
1. you would be hardening the resin along the path the laser moves from the object to "home". There would be a web of harden resin spanning the area between the object and "home"

The Peachy already has to cover some area withour hardening it, to move between parts of the job that are not actually connected (eg. if you print an H standing vertically then for much of the print you have to do a bit on one side and then move to the other side without touching the resin in between). Apparently the Peachy can manage this just by moving really, really fast so the laser doesn't have time to harden the resin.

With that said, it's possible that always moving to the same place (ie the target) would eventually cause issues. Maybe we need a whole home "ring" around the print bath so it can spread the load.

2. the object file to sound file convert software will now need to be far more intelligent as it will now need to know the spare time it needs to kill at "home" for each print layer. This is akin to software that automatically adds supports structures under print objects with overhangs for extrusion printers.

I don't think it'd be that hard. It knows the required Z height for each layer, and it knows the current Z height. It must already have some code that doesn't start the new layer until the Z height reaches the right level; if it started the new layer straight away then there would be no point in even getting feedback from the microphone.

I'd imagine that the algorithm is something like this:

while ([current Z height] < [layer Z height])
    [do nothing]
}
[continue with next layer]

The modification would just be:

while ([current Z height] < [layer Z height])
    [point at home]
}
[continue with next layer]

[Anuvin]

Looks like they are going to make a custom circuit to give the laser an on/off, AND they have been working on a point away solution.

[Slatye]

Awesome!

Lots of wonderful, wonderful details in that latest update. Very nice that they had a solution to the problem (eliminating the ringing so it can easily point away from the build area), and then went and solved it another way too (able to turn off the laser). It gives me confidence that this is going to be a printer "done right", not just "done until it works".

I am a little bit concerned about the need for an additional amplifier board. I'm sure that it'll work fine, but I'm generally reluctant to use any fixed-function circuit when for much the same price (these days) you can just drop a microcontroller on there and do all sorts of cool things (reading from SD, talking to devices that don't have audio input/output, auto-calibration without a PC, etc).

[Anuvin]

But which board and at what price? For $100, it's hard to ask for a good microcontroller. I know you can get an arduino for as little as $10, but that's 10% of the total price of the printer.

I really like your idea from the update thread about using a printed grid, but it requires a camera. Since I will be using a camera for 3d scanning, that is hardly an issue for me, but it does increase the hardware requirements. Since they don't provide a camera, they can't make calibration require one.

If they had a standard unit set for x/y calibration, it could be as simple as accurately measuring your container, and setting the laser to a central point and setting it as 0,0 right?

[Slatye]

But which board and at what price? For $100, it's hard to ask for a good microcontroller. I know you can get an arduino for as little as $10, but that's 10% of the total price of the printer.

I'd use an STM32F4-Discovery. Under $15 from Digikey, with the following specs:

168MHz ARM Cortex-M4 with DSP and hardware floating point support
192KB RAM
1MB flash
USB device
USB host
Audio output and dedicated audio DAC with amplifier for driving speakers
3-axis accelerometer
12-bit DAC (one dedicated DAC with two channels)
12-bit ADC (three dedicated ADCs with 16 channels)
Built-in programmer
14 timers (not counting the watchdogs and RTC), all 16-bit, many of which support up to four channels
All the usual communications interfaces - two SPI, six UARTs, two CANBUS, three I2C, one SDIO

I agree that with such a cheap printer, even $15 is a lot to pay. However, I'll be somewhat surprised if they can get their own amplifier board built for much less than that. When I was doing PCB design stuff, I found that once you use more than a few dedicated components (eg. maybe two 555 timers, a couple of op-amps, and a little bit of input filtering) it's cheaper to just stick a microcontroller on there. This also makes it really easy to add functions later. Want to read from a USB drive? The STM32F4 can do that. Want to drive some servos so you can fiddle with the valve or change materials? It can drive 32 servos at once, all using hardware compare channels. Need to detect shocks/vibration that'll mess up the print? It's got an accelerometer just for that. Obviously I'll plan to add this sort of thing to my Peachy as soon as possible.

I really like your idea from the update thread about using a printed grid, but it requires a camera. Since I will be using a camera for 3d scanning, that is hardly an issue for me, but it does increase the hardware requirements. Since they don't provide a camera, they can't make calibration require one.

Ah, good point. Most people will probably have a webcam, but I guess it must be possible to calibrate without that.

If they had a standard unit set for x/y calibration, it could be as simple as accurately measuring your container, and setting the laser to a central point and setting it as 0,0 right?

A little bit more, I think. To be able to hit the surface perfectly, it needs to be able to know its position and orientation with respect to the container and gravity (since the print surface is obviously horizontal with respect to gravity).

If it's precisely above the centre of the build container, then it just needs to know the height. This is because the distance between the centrepoint and the beam depends on the height difference between the laser source and the print surface. If you're drawing a line 100mm long, then if the beam source is 300mm above the printing surface then you need to sweep the beam from -9.46° to +9.46°. Once you print a whole lot and the print surface rises to only 50mm under the beam source, you need to be sweeping from -45° to +45° to get the same line length. This is obviously pretty easy to calibrate: you do a sweep from -20° to +20°, have someone measure the object, and from that it's trivial to calculate the height. Accuracy depends on how good the user is with a ruler. Repeating the experiment will help. An alternative is to have (for example) a 10cm square that you put in the print container, and move the printer up and down until what it's printing matches that square.

In a real system it won't be precisely above the centre of the build container. In this case the printer needs to know both its height and where the sides of the build container are. A method like the one you suggested would be fine. Either you can have it point straight down and move the beam source until the laser is on the centre-point of the build container, or you can measure where it's actually hitting and compensate for the offset in software.

Orientation is a bigger problem, or at least harder to explain. If what the printer thinks is "down" doesn't correspond to what gravity (and water) thinks is "down" then it's not going to print correctly. Suppose it's tilted so the beam is further forward than expected (ie when the printer thinks the beam is straight down, it's actually at 5° further forward). If it tries to draw a square around the centrepoint, the result will be an isosceles trapezium because one line is actually closer to the beam source than the other. If it's rotated in both pitch and roll then you end up with a quadrilateral, but exactly what sort of quadrilateral is hard to say.


I think that what is needed here is a camera calibration matrix (plus a known Z coordinate). This is because the Peachy is basically a camera looking at a flat piece of paper, running in reverse. It should be possible to compute this matrix given six point correspondences (ie points where you can match up a set of Peachy coordinates to real-world print container coordinates). More points gives you better reliability and robustness to errors/noise. Once that's done you can use the previous method to get the height.

[rylangrayston]

Its interesting that most of the talk here is about the z level .. I think this is the easy part, and many of the things suggested here will work!

Currently we are more focused on calibrating the x and y axis's
James has actually mapped the mouse to the laser. This lets you move the laser to shine on different parts of a grid, by clicking on
each point in the grid you collect data that is then used in a corrective functions withing the Peachy Printer software!


We plan to supply everyone with such a grid printed on paper.

Rylan Grayston