Evaluation

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.

Collaboration

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.

Endresult and Science Fair

Tuesday the 27th, we had a stand at the Science Fair. This meant that our hard work had come to an end and it was time to show the world what we had accomplished!

Sciencefair4

After rewriting the plugins that were used in the night before, we finally got the printers to work. Some tests in the morning revealed that the stepperdrivers were getting to hot, we added some additional code and added heatsinks on top of the stepper drivers.

Then, it was time to print!

This however only succeeded partialy, because of the printer bed leveling. This failed because it relied on multiple factors that were not adjusted correctly. We could have fixed this, but because of the lack of time, we were not able to test this properly.

Fortunately, the print method did work. This Poster finalkleinmeans that the printers were cooperating correctly and moving in the right order. The sliced object was properly translated to G-code which was visible in the movements of the printers.

To conclude on the concept: it works!
To make actual prints however, the machine needs to be finetuned (mostly callibrating and error-checking). We are glad to see that the concept that we started six weeks ago is an almost working prototype and proves that this is a possible new method of 3D printing.

 

At the Science Fair, people were really interested to see what we did. Most people didn’t get the concept at first, because they thought a bigger printer would solve all the problems. This shows how revolutionary this concept is, because almost everyone in the 3D printing world is working on making things bigger, instead of faster.

A pleasent suprise was that one of the co-founders of Ultimaker showed up to take a look at our project. Thanks to him and the rest of the Ultimaker community we were able to get additional information we would never have gotten ourselves.

YouTube Preview Image

 

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

G-code and more G-code

Right now we are thinking of a way to slice the object into parts, genarate G-code for it and then putting the different G-codes together in the right order. We are probably going to have to write a plugin that sorts these different G-codes.

But to create more strenght to the object, we want to have a little overlaps between the different layers, to make a masonry like structure.

printpatroon.jpg

By turning the pattern each layer this should suffice, but makes creating the G-code more complicated.

Another way to do it, is to split the solid object into parts in the 3D-software (for us that would be Rhino), then load it into Cura and assign different solid part to different extruders.

Using the plugin that the Kamermaker 2013 group wrote for the Master and Slave printer dividers, we can make sure that the printers move at the right time. This plugin makes sure that both printers are ready with their part by sending a message, before moving the X- and Y-axis.

However, it is quite hard for us to come up with the best result, since we are all new to the G-code world. For now, we’re still researching what the different ways are, and how to program them.

Building the framework

With the design shown in the previous post, we got our hands dirty and built the framework:
Framework_0.5

Once the outer rigid framework was complete, we could start adding the rails representing the X and Y direction frame for the enlarged printing area. The Z direction frame is fastened on the outer rails of the of the rigid framework as shown in the picture above. The two long vertical metal sheets facing each other allow the printers to be maneuvered up and down which are attached to the outer rails.

We are working with a configuration of two Ultimaker printers fastened together and hung between the horizontal rails as shown in the picture below. Using strips of sheet metal we constructed a way these two printers could be hung in the framework and be able to slide over these horizontal X-axis rails with wheels attached to the outer bends of the sheet metal, see to the picture below:

X railsmetal sheeting

 

 

As the two Ultimaker printer nozzles are limited by the spacing between the box of the ultimakers itself, we needed to construct a way the ‘overlap’ in between could be printed. This was done by letting the dual printer configuration slide over the X-axis rails, which gives them the freedom to move more than their overlap and thus print a larger object than they are seperately limited to. The dual Ulitmaker configuration will be controlled by a stepper motor which is attached to the rails, see the image below:

X direction framework

For the Y-axis frame, a bed is placed at the bottom of the rigid framework. The 3D object will be printed on this base plate and can move in the Y-direction over rails placed in the framework, see the picture below. With a 3 points constuction, the 15mm multiplex plate can be calibrated by a spring suppressing it. A mirror plate will be placed on top of this bed plate fastened to the multiplex wood with double sided tape.

Y direction rails

The base plate rolls on wheels and is controlled by one stepper motor attached to the base of the rigid frame work. See the picture below:

Y direction stepper motor

Coming back to the Z-axis frame, two stepper motors are used. One motor on each vertical rail. As these stepper motors need to lift the entire dual Ultimaker configuration and the framework they are fastened in, counter weights were needed on both sides to assist the stepper motors. The motors were not strong enough to lift this weight by themselves.

Stepper motors Z direction

Below is a picture of the final framework. We are all very pleased with the final result!

near completion framework

 

Designing the framework

Before we can start to test our prints, we first need to build the framework for the two Ultimakers to move in. As seen in the picture below, we want the Ultimakers to have external axis for the X-, Y-, and Z-direction, to increase the total print capacity.
The inside X- and Y-axis will remain there, but the Z-axis is entirely replaced by the outside axis, since it is not necessary for the printers to be on different Z positions.

Opstelling_metpijl

These ‘dubble’ axis will be created by extra steppermotors that are attached to rails.
The X-axis (blue arrows) and Z-axis (green arrows) will be moving the two Ultimakers, while the Y-axis (red arrows) will be moving the printer bed. We chose for this way because if the Ultimakers would also move along the Y-axis, they would create instabilities in the framework and even slight movement, that could result in print inaccuracies.

The framework itself will be made of aluminum profiles, which were used in the previous 3D XXL-project that worked fine.

Printing big, printing fast

As our desire for printing large object increases, our patience most certainly does not. Everything has to be done perfect, and it has to be done fast.
Ofcourse this causes problems. Nowadays the 3D printers we use can be tuned to go faster and even tuned to build larger.

Two years ago, during the same project (Kamermaker 2013 project) they combined two Ultimaker printers by creating a moving platform, therefor combining the print capacity.
Last year, during the Ultimakerxxl 2014 project they used the Z-Unlimited concept by Joris van Tubergen, and added a moveable X-axis. This resulted in a construction that was able to print way bigger than the regular Ultimaker sizes.

This year, we will be combining these technologies to print objects up to 700 x 350 x 1000 mm and much more important: fast!
We will be using two Ultimaker printers, turn them around, and put them on a moveable X-axis and moveable Z-axis. The Y-axis will be increased by moving the printing bed.
Theoretically, if this technology works, it will be able to combine even more Ultimaker printers (or other printers for that matter) to print large object even faster.
This technology could even be used for creating small objects faster, by combining tiny 3D printers.

But what are the problems?

Since the printerheads will never be able to overlap, it is necessary to move the printers or the printing bed, to fill the material in between to ‘original’ printing beds.
This then causes multiple problems:
-The printers will have to move to reach the ‘gap’, so extra moving X- and Y-axis.
-The software has to be able to know when to print what and when to move, since there are double X- and Y-axis.

To realise this, we will be converting the construction that the Ultimaker XXL 2014 project built to better suit our needs (an extra Ultimaker on the X-axis and a moving printing bed for the Y-axis. As for the software, we will have to write a plug-in for the G-code that slices up the model that is to be printed into parts. Each of these parts is corresponding with a position the Ultimakers are in when they are moved along the X- and Y-axis. This means to cover all points, it has to move 4 times. Each part has to be finished before moving on to the next part. This means that the Ultimakers have to wait for each other to finish the part before moving on.

If we manage to solve these problems, the next step to creating a fast, presice and large 3D printer is set.

 

Large Scale Ultra Detail 3D printing

Welcome to our weblog!

A little introduction:
We are five students following the TU Delft Minor Advanced Prototyping, researching the possibilities in augmented prototyping.
In our case, we will be exploring the possibilities in 3D printing ultra detailed objects on a large scale, by using multiple Ultimaker 3D printers.
Since large printers are not really new anymore in the 3D printing world, our focus will be on combining multiple printerheads, which will reduce the printing time rapidly.

We share the vision of our supervisor, Joris van Tubergen, that combining multiple printers to print one big object is the next step in creating fast, high quality prints.
During the next few weeks we will be posting our research results on this weblog.

Greetings,
Ruben den Uyl
Julian Ros
Mani Fares
Daan van der Valk
Thomas de Boer