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

Be Sociable, Share!