Idea: Print objects straight from your web browser

It just occurred to me that, because the Peachy Printer's only input/output is through a sound card, it should be possible to control it entirely from a website. (And maybe even a mobile one, though I don't know if the proper APIs are implemented yet in phone/tablet browsers.)

Would anyone else like 3D model gallery with a big 'print' button right on the page?

As soon as enough details come out (I'm not a Peachy beta tester), I'll start trying to make this happen. A further idea: combine this with an in-browser editor. It would be 3D design and printing with no software installation!

That is a neat idea and should work, though a lot or ressources are required on the server side ;-) of course newer browsers do support some web 2.0 javascript magic for audio too, but this would most likely not work on all browsers.
The most difficult part would be the real time audio drop feedback;
I am sure we will run into problems with non real time operating systems, but on a Brower based control software this might cause more issues ;-) still I find the idea awesome!

Quote:

---

Originally Posted by prototrout

It just occurred to me that, because the Peachy Printer's only input/output is through a sound card, it should be possible to control it entirely from a website. (And maybe even a mobile one, though I don't know if the proper APIs are implemented yet in phone/tablet browsers.)

Would anyone else like 3D model gallery with a big 'print' button right on the page?

As soon as enough details come out (I'm not a Peachy beta tester), I'll start trying to make this happen. A further idea: combine this with an in-browser editor. It would be 3D design and printing with no software installation!

---

That's a really awesome idea. Like Marcus said, I am sure it would take a lot of resources, but it is definitely something I think could be done.

The "Web 2.0 Javascript Magic" exists, but it's not everywhere yet. It's called Web Audio API. It should be possible to do everything in the browser, but it might not be fast enough; it will take some experiments to find that out.

Yes, I have seen some amazing things like javascript based augmented reality, qr code scanning...
But currently I am sitting on my ~6 year old netbook, and it's already difficult with some regular javascript heavy content :-)
But I am looking forward to this, it's a neat idea!

I've whipped together a little something. It seems promising. Let me know how it runs!

For me, it works in Chrome and sometimes stutters in Firefox (both on Windows). It should also work to some extent in Safari and Opera but I haven't tested it. To use it in Firefox, go to about:config and set media.webaudio.enable = true. (That will be the default in a future version.)

On Chrome for Android it stutters way too much. I imagine it won't work well on iOS either. Internet Explorer doesn't support Web Audio at all yet, so it won't work there.

In order to be useful for 3D printing, at least the following will need to be added:

• Loading/slicing 3D models
• Drawing arbitrary shapes/paths (right now it just does lines/triangles)
• Audio input and interpreting drip rate
• X/Y scaling and slice selection based on Z-level
• Setting the speed/beam width/etc. to match the printer

Is that you, Yoda?

Attachment 22

(From this model)

I haven't uploaded it just yet but I now have .stl file loading, tracing, and a rising z-level (faked; there's still no audio input done).

That version (with some improvements) is now live. It'll sound like static because I don't have line ordering done yet (the laser will jump around instead of moving in a circuit).

Let me know if you encounter an STL file that won't load. If it's stretched one way or the other, that's OK because I don't have corrections for that done yet.

Edit: Now it should support all STL files (not just binary ones). It even works (too slowly) with >100MB files.

Quote:

---

Originally Posted by prototrout

I've whipped together a little something. It seems promising. Let me know how it runs!

For me, it works in Chrome and sometimes stutters in Firefox (both on Windows). It should also work to some extent in Safari and Opera but I haven't tested it. To use it in Firefox, go to about:config and set media.webaudio.enable = true. (That will be the default in a future version.)

On Chrome for Android it stutters way too much. I imagine it won't work well on iOS either. Internet Explorer doesn't support Web Audio at all yet, so it won't work there.

In order to be useful for 3D printing, at least the following will need to be added:

• Loading/slicing 3D models
• Drawing arbitrary shapes/paths (right now it just does lines/triangles)
• Audio input and interpreting drip rate
• X/Y scaling and slice selection based on Z-level
• Setting the speed/beam width/etc. to match the printer

---

I love this concept, but it might be easier than first thought:

1) slicing can already be done with an existing program, just load the Gcode version of the file instead of the STL.
2) no need to predefine arbitrary shapes, just move the lasers wherever the gcode says to move and at the speed the gcode defines.
3) forget the audio input. If you use a symmetrical container and calibrate inches per unit time, then you just enter that into your web program at print time and it should be good to go...assuming your drip rate doesn't change.
4) you could scale x/y via trig math per rise in level, OR you could have a float system that supports the peachy and makes the laser rise with the water level. This way the laser is always in focus and it means you are not limited to short and fat vs tall and skinny, you could print tall and fat.
Attachment 28
5) the beam width should be set with a focus, and a floating laser means the focus is always accurate. The speed is about laser power. You can enter the laser power in mW into your web program along with inches rise per unit time and you are good to go.

All this together means more print volume with more accuracy and you don't need a mic input. Great for web based printing, even from tablets or smartphones.

The floating laser idea is clever!

I'll still design this to handle a fixed laser; not everyone will want to put the effort into making the laser float, so it will be good to support both. The trig isn't hard anyway. I'll also support variable drip rates because it will be more accurate and won't require calibration except when the container changes. (I don't want to assume that the drip rate will be perfectly consistent over multiple batches of water, atmospheric pressure changes, etc.)

I had thought about just taking G-code as input, but I don't think the format can cope with variable drip rates. It will work if we assume a constant drip rate, like you said, so we can have both. At that point, though, we may as well pre-generate the audio and there's no need for special software on the phone/tablet, just an audio file. That's great for low-powered devices that can't handle generating the audio in real time, but I want to get more accurate prints if I can.

There might be a mid-power, mid-accuracy solution if we have G-code (or something equivalent) for each Z layer, then use the drip sensor to decide when to switch layers. That should work even on phones. (Chrome for Android supports audio input but iOS doesn't.) That's my backup idea.

As far as slicing goes, why can't the laser function much like a DLP television? It basically sweeps in rows from left to right, one row at a time until it gets to the bottom, whenever the laser passes through an area that needs to be solid (cured) it turns on. This way there is no need to generate gcode-like data, all you need is to get the current layer in blender and recognize all the solid areas on that slice. No pre-computing where the laser should move or anything very complex like that, and the only signals you need to send via sound port are timings for when the laser should turn on/off throughout its ray-cast movement cycle. This will also allow you to print very complex objects with minimal pre-calculation and result in a much less error-prone print.

I understand that this causes the mirrors to move much more than before, how much will that affect the longevity of the printer?

EDIT: In addition, you could also setup min and max angles for the mirrors to move per print. That way, if you are printing an object that is smaller than the total build area, the mirrors have no need to move beyond the scope of the object size.