20. Final project development¶
Presentation output¶
What tasks have been completed, and what tasks remain?¶
I get to a point of the project in which I checked almost all the parts. Now I should rething the project to implement what i learned and essentially the improvement of Electronic Design and Production skills.
What has worked?¶
The idea to connect the mainboard machine to the raspberry pi computational module through a socket directly solder on the board, and interfacing the main functionalities through a WebApp to improve the best User experience is the goal that I’ve arrived during this weeks. This version is pretty light and easy to use. It’s actually possible to replicate the frame and electronics totally in a fablab.
What hasn’t worked?¶
The unipolar motors and uln2003a were probably not right for the purpose, in particular they are too small, as well as the drivers and the engraving speed is basically slow. In this version the machine is not particularely efficient in some cases.
What questions need to be resolved?¶
I would say that the main question is if this machine has any application and if it fits some lab’s needs. It would be very nice to find a way to replicate it in collaboration with some other fablabs.
What will happen when?¶
It’s hard to schedule a timetable of the development, cause it’s strongly influenced by the the access to some funds or facilitation. The first deadline is gonna be organize events around Engrave Cube machine, such as some workshops and through the European Makerfaire Rome, in October, where we will show the final projects of the fab academy students, collect some feedbacks. Considering the time I can allocate to this project it would probably take another 9-12 months to get to a package that can be made by someone else, with no problem.
What have you learned?¶
The main knowledge I’m going to bring with me after the fab academy, beside technical skills, is to get used to fail. I’ve learned to learn from my mistakes.
Documentation during development¶
Make the documentation during the project is incredibly hard: partially because to document everything is pretty confusing and uneffective. All the test to understand if a board works or not. Over a certain limit it’s just try everything, even things already done or obviously wrong. The output it’s not something already finished, but something easier to reorganize in a second moment.
Demand- vs supply-side time management¶
What I noticed is that the best way to switch from demand-side to supply-side is to count the time and resources backwords from the delivery, adding intermidiate milestones. Even if it’s not always working, it helps to understand the importance to change the way we use to schedule projects.
Spiral development¶
I’ve never heard about it before, but it was an increadibly useful suggestion. I changed the schedule of the development, dividing it into three “spirals”. The first one was to test main processes and user interface connect to the electronics separately, to check connections, assemble process, mechanical problems, dimensional mistakes, etc. After I spot all the possible mistakes (or at least as many as possible) I moved to a second version after i took note of all the problems on the frame and i decide to redo the PCB. Still the goal of the first step was reached: test the assemble, move the components by hand, separately, test the movement of the electronic, connect temporarely electronic and mechanic together and move the axis separately. The second spiral is the actual state of the development: I connected and assembled everything together, tested G-code sender and interpreter, moved the mirrors increasing their spped and found an alternative to the original solution. The third version would have been improve new WebApp UI or make an Android IOS app to control efficiently the E3.