Firmware plugins for AtCore

In AtCore we need to be able to talk to several different firmwares. Each has the possibility of being slightly different, but overall, they should be mostly the same. Some will support commands others don’t, and some will want specific commands with some extra info. This has lead us to decide upon a more modular plugin system in order to allow us to do any firmware specific stuff when we need to. Since my last post, we have added a few firmware plugins currently support the following:

•     Repetier
•     Marlin
•     Teacup
•     Aprinter
•     Sprinter
•     Grbl

They have all been tested on Arduino and the printing seams to work just fine. The Teacup and Marlin firmwares were hacked together while Lays was visiting some printers, so those, while not loading automatically at the time, have also been tested on a fully set up printer. We could just ask the user what firmware they have, but we don’t expect the user to know this all the time.

In order to figure out what firmware we’re on, we have decided to use M115. So far, while some have said its not the best idea, the only reprap type firmwares not to support it seem to be Smoothie, Grbl, Machinekit, and (according to the wiki) Makerbot (Sailfish). When your machine supports M115, you will get some text back about the machine’s capabilities and firmware. For example:

FIRMWARE_NAME:Repetier_0.92.9 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 REPETIER_PROTOCOL:3

Now, it’s pretty simple to tell from there what firmware name is in the string and load that one… It gets a bit more complicated when the M115 returns:

FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000

Wait. What happens here? Since when do we have three different firmware names on this printer. Since our firmware check only checks if the firmware name matches a plugin name by using QString::contains() the above example will pretty much try to load any of them since Marlin Sprinter and Grbl are in the string. Whatever one the plugin loader sees first will be loaded. Grbl is not the correct firmware for this printer, and that could be really bad if you’re trying to do some firmware specific stuff. Its looking like we are going to have to trim the string up to extract the firmware name from the string. Again not really a problem. By simply using QString::split(“:”), we can extract just the stuff after Firmware_Name:. After that, a simple QString::resize(QString::indexOf(‘ ‘)) will get us to remove anything after the first space. Now it works well. Then it came time to add support for Sprinter. M115 on Sprinter returns:

FIRMWARE_NAME: Sprinter Experimental PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1

At first, that might look okay, but notice after the : there is a space, meaning that in our existing name, extraction will fail. Because we will resize to the first space, our name will be ” “. Okay, not too bad to fix. Just check for and remove any leading space. Then another issue: what if the string has no spaces? Well in that case we might as just have just called clear. But that doesn’t happen right? Oh, wait, here comes aprinter:

ok FIRMWARE_NAME:APrinter

😦 . Not only does it break our check of QString::startsWith(“FIRMWARE”) to tell if it’s the firmware id string. It also has no trailing spaces. After all that, our current firmware detection does the following: Check if the message from the printer contains “FIRMWARE_NAME”. If it does, split the string at :. Keep the second one, and if there is a leading space, remove it. Then if there is a space after that, resize the string to there. It’s not too complicated yet, but its starting to get there.

And then there’s Smoothie. I was not intending to do this plugin yet because I don’t have hardware to test on, but I talked with a developer of smoothie in #reprap on Freenode. They were able to provide some interesting information about it. First off, it is not purely reprap-like. That means that it doesn’t follow all the guidelines for reprap firmware. For instance, they do not send start when the printer connects. This is important for us because it lets us know when to send the M115 command to the firmware. They also do not support M115 to get a version string. You must send the version command. Other then those two things, it works like any other reprap firmware. However, in place of start, they send a string of “Smoothie Running @ (speed)”. I suppose we can check for also Smoothie and start, and if we see smoothie, we know we need to load that plugin. This would also require revamping the way we check for firmware, since we now have at least one case where we don’t want to use our current method for checking.

There are a few other firmwares that I have not looked at since i don’t have the hardware to do the tests. This Hardware includes a MakerBot for sailfish, an ImpPro3d to for ImpPro3d, an Arduino Due (reprap fw), a Smoothie board (Smoothie), and a Beaglebone black (Redeem).