How to configure the OctoPrint plugin
This "How to" is dedicated to the configuration of the SMuFF OctoPrint plugin
IMPORTANT:
Before you configure the SMuFF OctoPrint plugin, make sure you have configured and flashed your Marlin firmware first, as described in this chapter.
If you don't do this in advance, the tool changes initiated by the OctoPrint plugin will fail because there's a mismatch in the number of tools (printer is supposed to reject requests on tools not present). Please read my hint on the OctoPrint Sanity Check down below before you get your hands on Marlin firmware.
Please notice: The method described here is meant to connect the SMuFF controller board via a USB cable to one of the USB ports on your Raspberry Pi, since this is the most convenient method of setting it all up, as shown in the picture to the left.
The other method, connecting the Raspberry Pi via the built-in TTL serial interface is described in the README of my OctoPrint plugin on Github.
In order to control the SMuFF via OctoPrint you'll need to install and configure my specific OctoPrint plugin, which can be found within the Plugin Manager of OctoPrint or in my Github repository. This procedure is mostly straight forward but you may want to do some extra steps, as the installation imposes some quirks.
After you've installed the SMuFF OctoPrint plugin via the Plugin Manager, you'll be able to set up its properties in Plugins -> SMuFF Plugin, as shown in the picture to the left.
After the installation, the Serial Port is being set to ttyACM1 by default, which might not be the correct one in your setup and hence, the Firmware Info field is most likely to be blank.
The Baudrate is set to 115200, which is the default on the SMuFF (change this, if you changed it on the SMuFF at some point).
Although ttyACM1 is a valid serial port device which becomes active after you plug in something to the USB ports of your Raspberry Pi, it may happen that on the next boot this device becomes ttyACM0. Thus, it's much safer to create a dedicated device using the name ttySMuFF, as shown in the screenshot of the SMUFF plugin settings.
To accomplish this, you have to walk through the procedure described next.
Setting up ttySMuFF
From version 3.17 of the SMuFF firmware on, I've changed the USB signature in order to distinguish the SMuFF controller easier. Hence, there's now a refined and easier procedure for setting up the ttySMuFF device, which works with either older and newer SMuFF firmware.
First, log in to your Raspberry Pi via SSH, make sure your SMuFF is connected via USB and then look up the SMuFF controller by typing in the following command:
udevadm info /dev/ttyACM* | grep "ID_SERIAL"
The console is supposed to respond with something like this, if you're running SMuFF firmware older than 3.17 (grep phrases are being highlighted in red):
E: ID_SERIAL=STMicroelectronics_MARLIN_STM32G0B1RE_CDC_in_FS_Mode_205D375C5341
E: ID_SERIAL_SHORT=205D375C5341
E: ID_SERIAL=STMicroelectronics_STM32G0B1RE_CDC_in_FS_Mode_20853152574B
E: ID_SERIAL_SHORT=20853152574B
The first line (in blue) identifies the 3D printer controller, because it contains _MARLIN_ in the serial ID, the second one denotes the serial number for this USB device in short notation (which can also be seen at the end of the first line).
The third line (in purple) identifies the SMuFF controller (and likewise, the short notation of the serial number in the fourth line).
If you're running SMuFF firmware newer than 3.16, you'll get something like this:
E: ID_SERIAL=STMicroelectronics_MARLIN_STM32G0B1RE_CDC_in_FS_Mode_205D375C5341
E: ID_SERIAL_SHORT=205D375C5341
E: ID_SERIAL=STMicroelectronics_SMuFF_3.x_5CF16F5C3532
E: ID_SERIAL_SHORT=5CF16F5C3532
It's the same as in the example above, except the signature now says "STMicroelectronics_SMuFF_" for the SMuFF controller board.
Now write down the string behind ID_SERIAL_SHORT= of the SMuFF controller board. In the examples shown above that's 20853152574B for SMuFF firmware pre 3.17, respectively 5CF16F5C3532 for SMuFF firmware 3.17 and newer.
Create now a new udev rule file with the name 98-usb-serial.rules by typing in this command:
sudo nano /etc/udev/rules.d/98-usb-serial.rules
You'll be asked to enter your password first, then, after nano has opened the file, copy and paste the following line into it:
SUBSYSTEM=="tty", ENV{ID_SERIAL_SHORT}=="5CF16F5C3532", SYMLINK+="ttySMuFF"
Make sure you've replaced the serial number with the one you've written down in the previous step.
Now save the file and exit nano using the Ctrl+S, Ctrl+X keyboard shortcuts.
Apply the new rule by entering these two commands (no need to reboot your Raspberry Pi, if you do so):
sudo udevadm control --reload-rules
sudo udevadm trigger
Now, to verify if the Raspberry Pi has assigned the ttySMuFF device correctly, enter this command:
ls -l /dev/ttyS*
lrwxrwxrwx 1 root root 7 Jan 29 11:17 /dev/ttySMuFF -> ttyACM1
If the ttySMuFF device is not being listed, make sure you go through the whole procedure once again.
If it's listed, you can write that device name into the Serial Port field of the SMuFF plugin configuration page in OctoPrint (as shown above in the SMuFF Properties screenshot), save it and restart OctoPrint.
If everything works as expected, the SMuFF plugin configuration page will now show you the Firmware Info and also the current tool state is supposed to show up in the status bar of OctoPrint, for example:
Before a tool change can be take place, you also need to set up a couple of additional GCodes in the Before Tool Change and After Tool Change scripts of OctoPrint.
Here're some sample scripts which you can copy and paste but don't forget to adopt them according to your printer / environment (position for tool change, that is - X, Y and Z):
;-------------------------------------------
; beforeToolChange script
;-------------------------------------------
G60 S1 ; save current positions (must be enabled in Marlin)
G1 X5 Y-15 F15000 ; move to change position
{% if last_position.z < 25 %}
G1 Z25 ; make sure the Wiper doesn't collide with the heat bed
; DONT'T use relative moves for this, it will cause the
; extruder to go nuts!
{% endif %}
M400 ; wait for move to complete
M84 E ; IMPORTANT!!! Turn off extruder motor!
; Don't switch the relay while stepper driver is
; under load! It may destroy your stepper driver!
G4 P250 ; wait for the relay to de-bounce
M106 T2 ; turn down cooling fan for tool change
@SMuFF LOAD ; tell SMuFF to swap tools
Attention Creality users!
As it turned out recently, most (if not all) of the original Creality 3D-Printer controller boards can't handle switching off only the extruder motor! This relates to the fact, that all stepper motor drivers share one common Enable pin. Hence, the M84 E GCode shown above will either not execute correctly or not at all.
Since it's highly recommended not to switch the relay under load (as stated above), you may use M84 (without the E) and turn off all stepper motors at once.
Switching off all stepper motors comes wit the risk, that the Z-Axis may drop during the tool changing process because of the pressure from the fed filament and thus might ruin your print, as the nozzle now sits too low.
Also, if your printer doesn't sit perfectly flat, the X-/Y-Axes may move forced by gravity, resulting in serious layer shifting after the print continues!
However, the only way to compensate for this is to replace your Creality controller board by a more sophisticated one.
;-------------------------------------------
; afterToolChange script
;-------------------------------------------
M106 T1 ; restore previous fan speed
G61 XYZ S1 F10000 ; restore saved positions
M17 E ; turn extruder motor back on for good measure
G0 F2400 ; Important! Reset to printing speed
Please notice: In the previous version of the afterToolChange script, I've had a M83 (switch to relative extrusion) before the G0 F2400 command. This has to be removed, otherwise your extruder will go mayhem! If you still have this code in your setup, please remove it!
In addition to this, you may want to add these lines in your "Before print job starts" GCode script:
...
M106 T127 ; set fan speed for tool change (~50%)
@SMuFF RESETAVG ; reset tool change stats
...
The first one will set up the part cooling fan speed for tool changes, which is being initiated by the M106 T2 GCode in beforeToolChange and restored by the M106 T1 GCode in afterToolChange.
The second one will reset the tool change statistics, which are stored within the SMuFF plugin, so you'll always start with fresh stats on each print.
Configure the printer profile
Now, there's only one more thing left to do and that is: Modifying your printers profile in OctoPrint, to tell OctoPrint your printer is able to handle more than one tool. Therefore open the Printer Profiles in OctoPrint, pick the printer of choice and click the pencil icon in order to change its settings.
Make sure you set the number of extruders accordingly and tick the Shared nozzle checkbox.
When that's all done, you can test whether everything is working correctly by heating up the nozzle and then opening the Terminal tab in OctoPrint and sending a tool change GCode, i.e. T3, to OctoPrint.
If you've done everything right, the SMuFF is will execute the tool change right away.
OctoPrint Sanity Checks
While you're at it, make sure that this option in Serial Connection -> Behaviour tab is not ticked.
As it's description tells you, if ticked, OctoPrint will ignore tool requests that are not configured on the printer itself. If this options is set, changing the Marlin firmware is mandatory. If this option is not set, you'll get away without the need for modifying the Marlin firmware.
Mandatory settings on SMuFF
In order to make the SMuFF work correctly, you'll need to enable the "Is Shared" option in menu Steppers/Servo -> Feeder and also the "External Ctrl." option. Set both options to "Yes". Keep in mind: The "Is Shared" option requires using the relay board (which you should always have, regardless of the printers controller).
In SMuFF-WebInterface those options are located under Settings->General "Use Shared Stepper" and Settings->Feeder "External Control".
Troubleshooting
In case the SMuFF is not accessible after the configuration of the plugin (the top status bar shows a gray -1), download and look into the octoprint.log file. Messages related to the SMuFF plugin are easy to filter by looking for the "SMUFF" keyword.