Part 1: Fixing g-code mistakes
There is a bug in the system. If a part of the object that should be printed by the slave is taller than
the part of the master, it will print the top part in the wrong place. This happens because the movement from part 1 to part 2 is controlled by the master, when the master thinks it’s done, it will go to its start position. However, the master no longer moves to the position to print part 2. I.e. the entire machine stops moving over the shared X-axis, resulting in the slave printing the different parts 1 and 2 at the same place on top of one another.
A possible solution would be by adding a small stick on top of the master, so the master will remain the highest and will therefore still send the signal to move to position 1 and 2.
Part 2: software iteration 1
We reprinted the top part to see if the shoulder is printed correctly. Result: negative. The problem still persists. Spending all afternoon figuring out what the problem could be turned out to be a matter of inconsistency in wait&go communication between the master/slave following in asynchrone printing (see test objects). This could be solved by a test mechanism. This will check if a toolchange is applied when changing layers. If this is not the case, a ‘fake’ toolchange will be applied. Currently a toolchange will not occur after a printer (slave for example) is done with its part. A less convenient way of solving this problem is by adding the wipe towers in all models.
Part 3: iteration 2 tool change problems
There still is a problem with the generated g-code if the print of the slave is higher than the print of the master. If the part where the slave is higher than the master is reached, the part of the slave will be printed at the wrong position. This is because the master controls the movement of the two printers. And when the master is done printing, while the slave is not, the master stops moving the entire printer. We control the movement of the printers by using tool changes. When the master is done, no more tool changes are added to the slave gcode file. So we came up with a plan: we decided to write a small Java program that could edit (post process) the gcode file. The program works as follows: after each layer it checks if there should be a tool change. There should be a tool change every other layer. The program also checks if the tool change is already there and only adds it if it is not there. The program worked well when tested in the digital environment, the tool changes were added into the places where needed. However after running the program on one entire g-code file we discovered a slight problem: something odd is going on with the changing of the Z-axis around a tool change. The Z-axis values were already applied in the slicer. So for example on layer 300 the Z-axis in the master was 60.450 and the Z-axis in the slave layer was 53.850. Our hypothesis is that when we would use this edited g-code the printer will print the neck part (that previously printed wrong and at the wrong place) at the right place, but partially in the air. We decided to print this to see what would happen.
We stopped the print half way, because we overlooked a detail. In the slave all the tool changes are the same, but in the master there are two types of tool changes. A left and right tool change. We only added left tool changes, so obviously that did not work well. We changed the program. G1 F5000 E-157.5 ; move external X to the right, G1 F5000 E157.5 ; move external X to the left
After these new changes we restarted the print with the following results. This print failed again like we predicted. But not in the way we expected it to fail. As mentioned before, the external X-axis movement should be fine now that the required tool changes were in place. But at around a height of Z=30mm (when the master shoulder is done printing) the master started printing the neck in the wrong place. This however made us realize why the Z-axis position was causing a problem in the first place. Because the master printer was done printing half of its work (shoulder), it does not need two printed layers at the same height. This causes the master printer to print the neck part at both left and right position. In addition to this misplacement of the neck, the Z-axis increases faster than that of the slave printer (because this is still working on to parts). A few minutes later the slave printer would also be done with its shoulder part and now also has only one part left to print. Within these few minutes the difference between the Z-axis placement of the master and slave climbs up till 6.60mm. From then on both printers have only one part left to print and the Z-axis difference stays at the same value. In contrary to the previous test, the printer now does move the external X-axis causing the printers to move left and right. The only problem now is that both printers continue to print their last part in both these positions. Our solution to this problem would be putting the printers at a “wait for other printer” status as long as it is in the X-axis position where it is already done printing.
Part 4: Octoprint plugin orientation
There may be a possibility that some plugins would allow us to use the Raspberry Pi as a 3d printing server. This means the Pi will send the g-code at the right moment. i.e. listen at a pin from the pi if the printer is done or not. Looking through all of them, these were in some way interesting:
Action Commands (Adds handling for user-definable action commands)
TemperatureFailsafe (Execute shell commands when temperatures violate thresholds)
OctoPrint-Enclosure (Control printer environment (Temperature control / Lights / Fans and Filament Sensor) using Raspberry Pi GPIO)
GCODE System Commands (Define G-Code commands that execute local system commands)
LEDStripControl (Control RGB LED Strips via your Raspberry Pi and GCode)
Touchtest Bed Leveling (A simple tool to move the extruder to different touch points around the perimeter of the print bed. Useful for bed leveling)
OctoPrint-Slic3r (Adds support for slicing via Slic3r from within OctoPrint)
Full-featured Slicer (A full-blown GUI-based slicer. Rotate and scale model; slice multiple STL files at a time; set layer height and other slicing settings)
CommandSplitter (Splits multiple commands on one line in GCODE files into multiple lines)
System Command Editor (This plugin makes System Commands editable through the OctoPrint WebUI)
Action Trigger Plugin (Plugin for OctoPrint that handles serial commands sent out by the printer).
Part 5: New g-code post processor
We further improved our post process of the g-code. Last week we started with a basis for this process. Several problems had to be solved. For example the extrusion for the newly created lines at the cutting section. Because new lines are created, a corresponding value for the extrusion of these lines had to be calculated as wel. This required an absolute extrusion setting in the slicer. This way we could easily add up the new extrusion. The amount of extrusion is simply calculated with the use of pythagoras between two points:
Testing early versions of the post processed g-code resulted in new insights of problem areas. The new extrusion values caused the PLA cable to break when extruded to fast. Because of this, the print stopt extruding PLA after about six layers. Another problem connected to the extrusion is the fact that several layers (infill, inner parameter and outer parameter) will be printed on the same place where the cut is made. A way to solve this is to divide the extrusion for this part by three or remove the extrusion at all. We still struggle with the offset of the four seperate parts to achieve a smooth transition. Another point we will be focussing on, besides the fact the layer and tool changes are now working properly, are the Z-axis changes. We discovered some faults when printing a test object. Sometimes the Z-axis moves too late and sometimes even in the wrong direction. Next week we wil be improving the final details to make a completely working post processor.
This week we also compiled a new version of Arduino and uploaded it to the master. These updates contain:
M92 code gives offset (from distance).
Hot bed pin has no security feature anymore. M42 P4 S0-150 now allows us to control the LED’s connected to the hot bed pin. The values 0 up till 150 correspond to the brightness of the LED’s. Check them out here!
Furthermore, in collaboration with the Robotics Stabilize machine we were asked to develop a connection between a human and their mechanics. This could show the power of the Ultimaker XXL. If we finish the g-code post processor in time, we should able to print a personal (3d scanned) back connection to the mechanics within just two days. This makes prototyping for the robotics department very easy and testing could become more comfortable.
Part 6: Final design Python program