Acquiring knowledge and reflecting
At the start of the project, no one really knew how a 3D printer actually worked. Some made a print before, others didn’t even knew the name Ultimaker. With two architecture students, an Applied Earth Scientist, a Mechanical Engineer and an Industrial Engineer, we didn’t have to best Electro technical background for this project. However, we rolled up our sleeves and got to work.
By trial and error we began to educate ourselves in the hardware and software problems that we were going to face during our project. With the group split in two, a hardware side and a software one, we started our research. While the one group was building the framework and attaching motors, the other group was getting acquainted with G-code and designing a slicing method.
At the end of project we got an almost working prototype, knowledge about the processes that accompany this project and prototype, and a clear vision about how to improve and optimise them.
Building the prototype
Initially the hardware construction went pretty straight forward, but we ran into a lot of trouble with the two supplied Ultimakers. The one from last year was already pretty mangled and the other one was pretty much in bits in boxes. With no actual knowledge of Ultimakers beforehand it took us a decent amount of time getting them both in a working state as just a standard standalone 3D Printer. This took too much time considering a four week project. Starting out with two working Ultimakers in the first place would have helped speeding things up.
When working on the software implementation of the communication between the two printers we stranded on the M42 software bug. Because we didn’t have a lot of knowledge of Ultimakers still, we didn’t really know where to begin problem solving. At first we thought we were doing something wrong so we kept at it, but after a couple of days we got the feeling it had to be something else. At this point we contacted our Project leader that we had no clue what was going wrong. Once he got involved we found out pretty soon (due to contact with Ultimaker) that this was due to a software but in post 2014 Cura versions. Our mistake was to try and fix our problems ourselves instead of contacting our project leader right away. That could’ve saved us quite some time. We could have saved more time by knowing what question to ask our supervisor, but since we were inexperienced, we didn’t know the right questions.
Contribution to the scientific community
As for the contribution to the scientific community , we were glad to be working with the Ultimaker community. This community is all about open source work and helping with each other’s problems. We contributed to this community by stumbling upon a bug in the Cura software. After having difficulty sending a pin signal from one Arduino to another, and having contact with people from the Ultimaker company, the problem was diagnosed as a software bug. It didn’t occur in older versions of Cura, but did in the newest, which we were using.
The wonderful helpfulness from the community came to exhibit then, because when this problem was posted on the Ultimaker forum, someone anonymous wrote an update for Cura that cured the problem. Long live open source software!
Besides this, we of course maintained our weblog and a post on the Ultimaker forum, creating awareness of our project. By letting people see what we did and how, everyone is able to continue this concept. It was nice to see that lots of people were interested in what we were doing, showing again how new this concept of multiple printers working together is.
Result in objects/prototypes
Unfortunately we were not able to get a full print out of our printers. This was due of lack of time to tweak the machine to perfection. Now, the machines do print, but because of calibration issues the print won’t stick well on the print bed. Also, we still were experiencing overheating problems on the stepperdrivers and sometimes the extruder head. All things that can be solved with a little more time. Because of this time problem, we didn’t get to do a lot of testing. This testing is important for optimising the print process.
Because of our multidisciplinary group containing it was convenient to split up the group.
We decided to go for a hardware/software divide, which worked quiet well. It was effective to work this way and little double work was done.
Even though not a lot of knowledge about the subjects was present prior to the project, everyone worked very hard to acquire these skills and knowledge. The work environment was very stimulating and all were involved in all the decisions and progress. We are all proud of what we have manged to accomplish in these short weeks and will walk away as enlightened 3D print-prototypers.