Results, Responses, and Reflections

Compiled for the EMM Lab by W. Kees Schuller. With thanks to Swati Mehta for web support, and Dwayne Collins for 3d file support

Build Results

First Build:

Once assembly began, I immediately encountered issues. While we had the necessary parts, and some assembly could be done (such as combining two timing belts into one timing belt of the required length), the majority of the assembly couldn’t be. The issue was that the 3d printed parts did not have the accuracy of the laser cut parts used by the designer – as such, many of the components didn’t fit together like they were supposed to. While drilling, filing, or otherwise re-shaping the parts worked for some of the components, a majority of the 3d printed components were not viable, even after these modifications.

Re-printing the parts at a higher accuracy and specificity (using the highest settings on the 3d printer, an Ultimaker S5 3D Printer) still did not result in viable parts, either due to a lack of accuracy, or due to the 3d files not being correct.

Simply scaling up all the parts when printing would throw off those measurements that were correct, which meant that the 3d files needed to be redesigned – something I didn’t know how to do. Learning that skill set added time to the project, and while I was able to re-shape the files, my new versions were often just too large for the components, which would have resulted in a wobbly and inconsistent print. However, they were sufficient for assembling a test-build that could then be iterated and improved on.

Second Build:

After redesigning and reprinting the files, and salvaging the parts for use in this new, redesigned 4xiDraw, the device could be assembled a second time.

This version, unfortunately, had other issues – once assembly was able to progress, I found that some of the new 3d printed parts would not work as intended (being too large), and so had to combine original-design 3d parts and new-design 3d parts. Alongside this, the component list provided in the instructions is incomplete – additional parts are needed to build the 4xiDraw, but are only listed in the body of the instructions, and were referred to by industry terms, rather than specific part terms, which made sourcing them difficult.

In spite of these further delays, I was able to complete the 4xiDraw build, though at larger costs in time, effort, and money than originally anticipated.

Programming Results

The programming component of the project was supposed to be relatively straightforward – installing Inkscape was, as was converting images for use. However, issues again arose when trying to use the custom addons designed to operate the 4xiDraw.

I was not able to get either the original addon or the updated addon to work as intended. This might have been due to updates to Inkscape software, issues with the addon installation (though I uninstalled and reinstalled multiple times, following the guidelines provided, as well as other, alternatively sourced installation guides), or possibly due to mechanical issues.

Ultimately, rather than continue to work with the programs that were not working, I switched to direct input of commands to the 4xiDraw from the Universal GCode Sender program, which was functional. However, at that time, I discovered that there was a critical fault somewhere in our 4xiDraw build. While instructions could be sent by the computer, received by the 4xiDraw’s Arduino processor, and then forwarded to the motors, the motors themselves were not able to execute them.

When the motors were issued a command to engage in any number of rotations, their axles would progress slightly, before vibrating violently, and returning to their starting position. This occurred no matter the input. I obtained an alternate power supply, re-wired the 4xiDraw, reprogrammed the Arduino, re-installed the computer-side programs, ran the motors dependently and independently of both each other and the 4xiDraw frame, and attempted various modifications to the command prompts in hopes of generating a different result. Unfortunately, however, I was not able to get a different result, suggesting that the cause is an electrical or mechanical fault in both motors, in the wiring itself, or in the Arduino, an assumption that was supported by the developer of the 4xi, who provided some additional tests that also suggested the fault is in the components, rather than in assembly or programming. This last suggestion is also supported by the other fault I experienced, where, in spite of following assembly diagrams (and then trying alternate circuitry connections after testing), the motor commands were not being sent to the correct motors – specifically, sending a command to either the Z motor or the Y motor triggered the Y motor. This may have been an assembly issue, but, as it persisted across multiple re-assemblies, and across switching output ports, I believe it was not.

While it would have been possible to source new versions of all those parts and continue the project with additional iterations and tests, Dr. Pasek, in her role as lab director, decided that after a year of working on the 4xiDraw, further efforts would lean into the sunk cost fallacy, and to conclude the project, calling the experimental build non-viable for our purposes.

Reflections

While the 4xi ultimately didn’t work, it didn’t necessarily fail. Partly, this is because there are numerous lessons that I have taken away from it (and shared with the lab as a whole), and partly this is because the goal of the build was to assess the viability of the 4xi as a budget-friendly option for future lab projects.

To address the latter “success” first, this project has failed as an actual build. The 4xiDraw has proven to be difficult and costly to assemble (with a total material cost of 580.77 CAD, which is comparable to the 599 CAD cost of the iDraw), and has been time consuming, requiring around 150 (non-consecutive) labour hours over the past 2 years I have been working on it.

Further, even if the 4xiDraw had been functional (without the technical issues that led to the cancellation of the build), it would not have been particularly useful – the multiple scales of 3d printed parts, modified parts, and assembly issues have led the 4xidraw to be somewhat physically unstable and imbalanced. The pen carriage does not sit firmly in place, and the guide shafts shift in their holders. While this could have been addressed with further modifications (such as super glue, padding, additional reprinted pieces, etc), it still would not have had the accuracy of a machined pen plotter like the iDraw, making it difficult to use it for the precise work required by the planned future projects.

However, the failure of the 4xiDraw for the planned project (as a low-cost, accessible, easy-to-build alternative to professionally produced pen plotters) was a possible result of the experiment – in this respect, the experiment was a success, as it has proven, at least for our purposes, that the 4xiDraw is not a suitable substitute.

Returning to the other success, then, of lessons learned, the 4xiDraw build has led to numerous new “best practices” within the lab when working with open source objects and devices, some of which improved the build process of CYAN (see CYAN for more information).

These best practices are drawn from my experiences during the process. Working with open source projects means relying on the expertise of someone else – or, if there were multiple contributors, then the expertise of multiple others. This leads to both potential pros and cons. Leading with the cons, open-source hardware projects are built on assumptions – made both by you and the hardware designer – about the difficulty, about your capacities, about the clarity and accuracy of instructions, and about access to tools. Invariably, some or all of these assumptions will be wrong. They might be wrong on the end of the hardware and documentation designer, assuming that you are more or less competent than you are. It might be on your end, assuming that the documentation is more or less complete, or that your tools are or are not adequate. These assumptions may give way to new assumptions partway through – perhaps that the instructions are incomplete, or your tools are inadequate – only for those new assumptions to be proven wrong, because you instead assumed yourself to be smarter, more competent, more skilled, or more correct than you were (or vice versa). There is no easy way to dismiss these assumptions without simply working through them. These assumptions I’ve listed are all ones I came up against – the 4xiDraw promises to be a shorter project that should take “about a weekend,” but which took me much longer. Similarly, I first assumed that the instructions were complete and correct, but as errors and inconsistencies mounted, I started, instead, assuming that much of the instructions were incorrect – which meant that, when a later issue was due to my error, I instead assumed it was an instruction error, something which took up time to fix. And, if multiple people contributed to a project at different stages, the chances for error are increased, and the chances that a contributor is no longer actively checking, or that their contribution has broken in their absence, increases.

At the same time, though, working off of someone else’s designs has positives. First, they’re more likely to have been attempted by other non-experts like you, and hopefully have had some of these errors addressed through wider testing. Further, working off of an individual or collective’s designs means that you can contact the designer(s). Having that avenue of approach, the ability to reach out to the designer directly, is something that is often not possible with corporate designs, or when designing something yourself. And, in our experience, the designers are happy to provide suggestions, support, advice, or answers.

Moving to our best practices, then, rather than just thoughts:

1. When starting a project, make sure to read the instructions fully before beginning work.
   1. Try to ensure that you understand each step, and what is being asked of you at each step – you need to have a project that is within your skills, or that you can acquire the necessary skills.


2. Ensure that you have all the necessary components.
   1. Double check the components list in the instructions with the components mentioned at each step of the instructions.
   2. Make sure that, when ordering parts, larger kits or sets come with the parts that you expect them to.


3. Make sure that you have the necessary tools on hand.
   1. Make sure that if you have a generic toolkit that it is equal to the requirements of the build and has all required tools. Double check your tools in advance of needing them, rather than assuming.