Ah, yes, that can be an issue.
Fortunately, my potential veto thought the printer was as cool as I did. 
Donāt le sigh, be confident that anything you want to make you can either:
a) rent time on a local makerspaceās machine,
b) send it into any of the numerous 3D printing companies and have them make it for you on their much-nicer machines that are well maintained and have a myriad of options
Having done both, I actually recommend b for a lot of the things people want to print, not having to screw around with the Z axis or someoneās weird RAM issue or whatever is totally worth the much nicer end result.
Iād love one too, but I openly acknowledge that Iād never print enough stuff to own one.
If I could make good Games-Workshop knock offs it would so be worth it to me actually good minis for anything would be cool.
I like this option, because I know that the tech is young and the machines still fuck up a good portion of the time. If I order it from someone professional, the screwups come out of their budget instead of mine.
Exactly. I needed a snoot for a flashlight, so I mocked it up on a local 3D printer, kicked around some design ideas and then had one professionally printed. The one I did took over an hour and was prone to the lumpy plastic separating. The pro one has been through a ton of drops and still holds together, looking much nicer in the process. I donāt even know what I paid for it at this point but I do know that it was still a bargain.
You can get to 90+% success rate, probably fairly easily.
I keep having problems (very few bigger attempts so far, and it is getting better) with filament skipping/grinding. That could be alleviated by sensing the physical movement of the filament (a wheel with an encoder), correlating it with what goes to the motor (or the movement of the actuator cogged wheel), and pausing the print in case of discrepancy.
Pronterface is opensource and written in python. Shouldnāt be difficult to run it on a raspberry pi, and having the encoder (perhaps a gutted balled mice) on the other USB port and hack the software to take a signal (SIGUSR, or perhaps even listening to a TCP or UDP port?) for pausing. Given the power of the newer Raspi board, and especially the other alternatives, other effects like nozzle knocking the object or detachment from the bed could be detected by machine vision. (Thought: watch the printer bed, look for major movements below the nozzle plane.)
Sounds like you need the more expensive but also way more accurate and faster photolithography machine. See http://www.makerjuice.com/ for example vendor of the goops.
I entirely agree with the premise of the article.
Get cool things done by somebody else. Get her used to the thought of printing stuff. Occassionally, not too often, float the idea of owning the machine.
Ohh still not quite the quality of the good mini manufacturers but damn nice and it would matter how may toys you can get from a liter of goo.
Not counting the dead volume you need, a cubic millimeter of the goo is a cubic millimeter of the object.
I saw designs where the total volume is minimized by using just a thin layer floating on water and exposed from top. The z-axis shifting was done by dripping in water.
The dead volume can be also minimized by printing from bottom, by exposing through the bottom of the vessel. Then you need just a relatively thin layer on the bottom.
The volume of the object can be then minimized by printing it as an outer shell and sparse inner reinforcement. A hole to drain the unused goo has to be included. I wonder if there are slicers that take this into account.
I am thinking about the possibility of a dual-wavelength UV resin printer. One wavelength polymerizes, the other also cross-links, so you could get elastic and rigid materials from a single resin mix. Another possibility is that one wavelength makes a weak, soluble material and the other one a strong, insoluble one, which would allow easy printing of supports. But this is a question for a photochemist.
This is probably the single best use-case Iāve heard suggested yet for larger-scale adoption. There are a /lot/ of gamers out there who play figure-based games, and many play more than one. A printer thatās only big enough for figs could certainly be made at a price significantly lower than a single army of pewters.
Pewter not used for the big players anymore. Metal costs have pushed things to resin for smaller count runs and injection mold plastic for anything big or need a lot of. And honestly the detail on the plastics now is amazing.
I indiegogoed that about a year or two ago. Iāll let everyone know what itās like if it ever comes through.
I know thereās been modifications to do things like wait for a layer to print before taking a picture with a webcam. Problem is, what youāre talking about would probably need to be done on the printerās controller itself, since pronterface sends higher-level commands to the boardā¦ I donāt think youād be able to dynamically handle things like flow issues from the system running pronterface all that well. You could certainly pause after the current instruction is done, but continuing from there without a quality issue would be difficult.
Not that high-level. The commands are G-code, which tell the printer to move to coordinates at speed, run the extruder, and do some high-level functions (e.g. autocalibration). You could monitor the commands, either in hardware (tap the Rx/Tx lines of the controller) or in software (run the data stream through a proxy that āteesā one source to two sinks). But you may not even need that; worst case, you lose more than a part of a single layer as it reacts late.
Essentially, you can easily(ish, if you solve the machine vision part) emulate an operator sitting at the machine and watching the paint dry (okay, plastic deposit) and pressing a button when something goes wrong (filament not moving, printout object movingā¦). No need to see into the communication between the printer and the computer. All you need is a separate process (or two, or three), independent on everything else (maybe semi-independent, getting signalled if the print is running or not), watching if things are okay, and sending āSTOPā to the g-code feeding process when they are not.
This is exactly what I do. A while back I designed, engineered, and built a household grey-water recycling system. Others became aware of it, and wanted something similar. I formed a little company that makes and sells the plans and parts. Some of the parts were kludged together, cut and glued by hand, which works for a one-off but not for small production volumes. So I borrowed a 3D printer, but what it made wasnāt strong enough for permanent parts.
I ended up sending out the plan to a real 3D printing company and they made me a couple of prototypes for about twice what I spent trying to do it myself. The parts still werenāt strong enough for permanent installations, so I found an outfit in China that will make steel versions. Those work, and if you factor in my time, theyāre still cheaper than the handmade versions.
Yes, thatās what I was saying. G-code is āhigh levelā in comparison to the actual moment-by-moment movements of the printer, so (from my experience) you would have to wait for the conclusion of the current instruction before you could interrupt if youāre doing things up at that level. In the versions Iāve worked with Iām pretty sure there wasnāt a way to immediately interrupt the current process (and I several times wished I had one when I was starting out).
Depending on what you want to do in response to the problem, this could cause issues, especially if the problem happened in the middle of a long segment of the model. Not necessarily insurmountable issues, but not completely straightforward ones - particularly since the pronterface computer likely wonāt know the exact point where the head was when the problem happened.
I seem to remember seeing a project some time back that actually handled filament-out issues and used a webcam to locate the spot to re-start the print, but it really feels like that would be easier to handle at a lower level.
Ahhhh. Iād consider G-code to be āfairly low-levelā, a level above the actual pulses to the stepper drivers. (See LinuxCNC controlling parallel port. Or Marlin (or other printer firmware), running on the microcontroller.)
Yes, this way you have to wait until the conclusion of the instruction.
There may be a way to suspend the controllerās operation. Would require modding the firmware and using a GPIO; if that pin is pulled down, the operation is immediately suspended, and continues after the pin is released.
But usually such fast operation is not needed. If there is e.g. an impending tool crash, the reset button can do the cancel-everything-NOW operation.
Could be nice to implement g-code for āstop NOWā or āinterrupt NOWā, thoughā¦
Absolutely. Itās mainly a matter of the perspective youāre looking at it from.
For me, if the last instruction I gave could mean I need to wait on the order of minutes before I can yell āSTOP!ā, Iām still working at a higher levelā¦ even if that level is pretty low-level instructions. 
Iāve actually considered figuring out a way to do just that. Unfortunately, different setups of controller boards are all over the map as far as whatās available for GPIO. You could tie something right across the reset pins, but for a lot of things it would be really nice to get feedback of where the controller thinks the head is beforehand.
Boy, weāve gotten a little off-topic here.
That could work.
Usually a #define in configuration.h could take care of this.
Hard reset is a last resort.
