I’ve been racing to get my printer done before spring break starts (now) and I leave for a conference next week (Tuesday). The X and Y decks are in, the power is in, the boards are mounted, and endstops are mounted, the Z deck is in… but… I managed to destroy two of the three ribbon cables used to connect the motherboard to the stepper boards. Not sure how I’m going to replace them as they are no for sale on Makerbot.com. Looks like it’s time to email Bre.

Additionally, while building the plastruder, the insulation tape ripped and I am very unhappy about how loose it ended up being around the print heater. I am likely to order a supply of new items, like the insulation tape, to eventually replace it (summer)?

I’m angry at the build directions, as I can not find how the endstops should be connected, how the wires should go, and if I need to wait to do this. If one follows the directions to a “T”, you would not connect them. Finally, I completely don’t understand the popsicle stick and endstop directions. Can someone post a good close of series of photos of how yours looks? I’m not clear on where I’m gluing the sticks, size of the sticks, where they are placed, etc. The directions are far, far too vague.

We started some private discussion about what the user interface of the software portion should look like, how it should function, where the software should be stored (on a server or locally) and other logistical things.  One of the objectives is to make the software as portable as possible across as many platforms as possible.  This goal would probably be most easily achieved through a server-side software configuration that can be accessed via a web browser.  This would also make our challenges with accessibility a bit easier as well, since any modern screen reader will be able to handle a web interface right out of the box.  After all, the web is the future, right?  Of course, this does have some security issues we have to keep in mind.  For example, who will have access to this service, especially when it’s in its initial stages, and how can we control user access?  The first idea that comes to my mind is that we could put this service behind a firewall of some kind, and allow only certain people access through the firewall.  On the other hand, let’s say we go with the approach of storing the software locally.  We may have some accessibility issues to address.  Most screen readers communicate directly with operating system controls to provide the feedback that they do.  I reported a while back on this blog about my findings with virtual box, something I didn’t have much success with on a count of it using QT.  QT is useful because it makes it easy to make software more portable, but many screen readers will have trouble with it without some kind of modification, as they do not use standard operating system controls.  These are some of the design issues we are considering, and obviously there are tradeoffs either way.

I don’t recall us having any trouble with the bearings falling out of the pulley wheel. Actually, we had the opposite problem, and had a hard time getting them in because they were so tight. As for a solution, you could glue down the bearing, although, keep in mind that the bearing/pulley assembly will be bolted down.