Setbacks in the Project

In the week prior to the exhibition the main focus was on getting the communication between the Ultimakers up and running. This meant connecting the motherboards of each printer with a simple 1-bit communication wire and customizing the firmware to allow pulses to be send and received. With guidance from forums, our coordinator Joris van Tubergen, and our special guest Ewoud van Munster, we were assisted in the situation, although most was performed by the group itself. Ewoud worked on the same project in 2013 and managed to get a communication going between the printers with one movable axis, being an enlarged X-direction bed which moved within the configuration of the two ultimakers itself. In our case we have two more dimensions the two printers could move, being an external Y-bed and the ‘unlimited’ Z axis. But in the process of applying the customized firmware and G-codes we ran into problems we could not grasp… This was not due to our misunderstanding of how the electronics worked or not knowing how to use the commands, but it was an issue with the current editions of the firmware in combination with the Gcode commands! Somewhere in a firmware update between 2013 and 2015 it did not allow certain communication codes which we intended to use. A solid 3 days were spent with our hands in our hair trying to figure out what this problem could be. We thought of every other external factor that could play a role, but never questioned the firmware itself… On a desperate afternoon we had a skype call with Joris van Tubergen, as connected as the man is, he contacted some of his buddies at the Ultimaker company. They indeed confirmed that they too seemed to have issues using the codes we were using, experiencing crashes within the firmware.

In the mean time, we decided to download an older version of the firmware to see if this really was the problem. We downloaded a version from medio 2013, thinking Ewoud’s group would have used the same firmware at the time. We updated our Ultimakers with the firmware and were extremely relieved to see the communication did work. With a program called Pronterface we could send codes from our laptop as a host in real time, instead of having to update the GCode scripts and input them into the printers via SD card. This saved a lot of testing time.

It was a relief to see that this was an external problem out of our control, but obviously did not satisfy us at all. It was Thursday and the deadline for the project was the following Tuesday… We continued to do some tests with the working communication, using the voltmeter to manually figure out how strong these pulses were, and to see which pins responded to certain codes input via the Pronterface host interface. We could also test the response of the pulse by assigning LED pins to emit light once signaled with the codes. This was satisfying to finally see working.

In the afternoon of Friday, we ran into another major setback. As we had heard of no solutions from Joris or the Ultimaker programmers we continued using the older firmware. We had to make customizations to the firmware specified to our parameters within the project for it to work. It all went smooth until one ultimaker just ran into critical errors! Some stepper drivers just went on overdrive and burned through, one after the other… and this led us to having only one working printer, which was useless because the printers are rigidly connected together and need to work in sync to move up and down the Z axis. It was 16:20 in the afternoon, and the only option we had to get working stepper drivers was to go the RepRapworld, a shop dedicated to 3D printer parts, located in Nootdorp 30 minutes away by bike. We had no time to waste so frustratedly jumped on our bikes to make it in time before the closure at 17:00. This all worked out and we came back to the lab with six new stepper motors and a new arduino.

Joris has been in close contact with the programmers at Ultimaker and has now given us good news that the current firmware versions have been correctly adjusted and compiled to allow for the communication codes to work. Over the weekend the new arduino has been tested and it responds well to the commands. It is now Sunday night and tomorrow promises to be a long and exciting day, hopefully with lots of ups and minimal downs… but as the project has proven, that is an ambitious request.

The Middle Man (Firmware) and Communication Workflow

In the last few days half the team has been fine-tuning the hardware side of the project. The other half have indulged into the world of Utlimaker software and the workings behind it. What connects these two aspects together is the firmware which takes the software and communicates it to the hardware. The firmware used with the Ultimaker printers is called Marlin which is embedded on the motherboard by a micro controller called an Arduino. This Arduino controls the inputs as code to the many sensors and chips controlling the printer, giving it life.Arduino

We have made some customization in the firmware to control the ‘steps per millimeter’. As we had connected the original internal z-axis to the external z-axis motors, the amount of revolutions the stepper motors had to perform per millimeter differed to its default settings. As the belts and pulleys used on the external z-axis are larger than the belt sizes for the internal axis, the parameters used to calculate these steps per mm had to be adjusted to the new specifications of the belts. These recalculations led to successfully calibrating the z-axis allowing the movements for each stepper motor for the external axis to be the same steps per mm. Other settings adjusted were print bed dimensions and the amount of extruders applied to each Ultimaker. Extensive hours were put into tests for the calibrations and playing around with the firmware to optimize the settings for our project, without it the prints would be of very poor quality or potentially not give us the output we expect at all… The Ultimaker allows for connection with a laptop via USB, then using the
designated software for Arduino, we could compile and update the firmware each time.

Getting along with the G-code has been a brain busting and challenging experience. It has been a tedious process figuring out how the printer responds to certain G- and M- codes and still feel like we do not have a good grasp on how the the printers respond to certain adjusted inputs… We are working with a Master-Slave concept between the two ultimakers. This means that one of the Ultimaker leads and allows the Slave Ultimaker to communicate with the master to be allowed to do certain tasks. We are testing this with two Ultimakers at the moment, but this configuration could potentially be adopted by a master controlling multiple slaves.

The communcation between the two ultimakers is done by a simple yes/no impulse which is requested by the master by a M601 code over an digital pin connected between the two arduinos. The slave can then return a command M42 which can be set on or off by giving it maximum or minimum output. The command can also be done from the slave to the master to allow the slave to do a certain action, but with permission of the master. This method is integrated in our project as will be explained below:

First of all, both Ultimakers have two extruder motor channels which is used to control and give power to the filament extruders. The second channel is placed for a potential second extruder head, but has only just been recently made possible in the world of 3D printers. We are using this second extruder motor channel to control the external X- and Y-axis of the frame. The thing is, only one extruder motor channel can be used at a given time. Our idea is to apply the external X-direction movement to the Master’s second extruder channel and the extern
al Y-direction movement to the Slave’s second channel. For this to work, the Ultimakers need to communicate about when movements in either the X and Y direction can be made… In the G-code plug ins we are working on allow for switching between the extruders and communcation between the master-slave printers to allow for seperate X and Y movement. The flowchart below portrays the generalized schema of how this is done:Flowchart_master_slave