Update: 11/18/2013 – I added a discussion of the platform size settings, which had previously gotten left out. Also added mention of the X-max pins setting, and the new QU_BD-specific macros.
In a previous post I wrote about the process of installing Repetier firmware on a 3D printer – specifically a QU-BD Revolution XL. In this post, I wanted to highlight the various configuration changes that I made to the Configuration.h file in order to customize it for the RXL. Many of these changes are copied directly from the source files provided by QU-BD, while others are based on my own preferences, and also the fact that I have added a Viki LCD controller to my printer, and need to set the printer up to support that.
The changes that I made are specific to my setup of RXL printer with Azteeg X3 electronics, and Viki controller. I believe that it should still work correctly without the Viki installed, but haven’t tested it (as my original reason for updating the firmware was to get my non-functioning Viki panel working). If you have a non-XL Revolution, then I think it should work, although you will at least need to change the travel dimension settings. For other printers, you’re on your own, but at least the discussion of the settings below should be a useful starting point.
Enabling the Viki Controller
Note that in addition to the changes in the configuration file that I’m highlighting here, I also made a few other changes to other files, to stop the Azteeg X3 and Viki configurations from conflicting with one another. Therefore if your primary aim is in getting the Viki to work on your X3 electronics, then I suggest that you review all of the code differences in this github commit (and/or work from my fork of the code). Note, those changes are not really intended to be robust in situations where you don’t have an X3 and a Viki together – I simply needed a version that worked for my set up; I’ll worry about making it more robust later.
If you don’t have a Viki controller, then setting FEATURE_CONTROLLER=0 should be sufficient to disable it, and allow the rest of my version of the firmware to run correctly.
Reading the File Diffs
The screen shots below are the ‘diffs’ that show the differences between my version of the Configuration.h file (available in my fork of Repetier, here) and the canonical Repetier version that I worked from. This shows both the original lines that I replaced (highlighted in red), and my replacement lines (highlighted in green). The line numbers to the left show where the changes are in the original and customized files, respectively. In each case, I show the edit first, and then describe the rationale for the change underneath. In other words, in the finished file, the red lines are gone, replaced by the green ones.
Note that the line numbers may be slightly off if additional code gets added at the start of the file (such as my QU-BD-specific macros discussed next).
To make it a bit easier to set things up for QU-BD printers, my fork of the firmware now includes some macros to specifically enable some features such as the Viki Controller and X3 board, and to flip the X-stop wiring (as discussed at the end of this article). As with other C code, just remove the ‘//’ at the start of the line to make the feature active – or add the double slashes back to make it inactive.
Configuring Repetier Firmware for the QU-BD RXL Printer
This first change is to specifically set the motherboard type to be the X3 (i.e., type #34, as listed in the table that precedes these lines), rather than a generic RAMPS configuration. By extension, this enables EEPROM settings storage capabilities. (In later versions of my fork, this is done with the QU-BD specific macros, discussed above).
Here we are setting the appropriate number of steps-per-mm for the three primary axes. These values are based on what is in the code QU-BD published.
Similarly, we set the steps-per-mm for the extruder motor.
Again based on QU-BD’s code, this sets the type of temp sensor used on the extruder – specifically a hard-coded lookup table. The actual table gets set up below.
This defines the control logic for the extruder – basically whether the motor needs to turn clockwise or anti-clockwise for ‘forward’ movements.
These next few changes are copied directly from QU-BD’s code. This first one sets the starting feed rate and acceleration for the extruder.
These are the initial PID settings that define how the extruder temperature is monitored and controlled. You can auto-detect tuned values for these parameters by running the self-tuning gcode M303 in Repetier or another interactive gcode execution environment.
This sets up the extruder cooling fan settings: I’m not sure if this actually used on the RXL since the head cooling fan runs constantly; perhaps it is used for the electronics cooling fan?
This is the thermistor calibration table for the extruder temp sensor. You will probably want to copy and paste this from QU-BD’s original file.
These set the range for the thermistor table, above.
This sets the maximum allowed temp for the heated bed.
This is taken directly from QU-BD’s code. Honestly not sure what it does.
This sets the maximum operating temp for the hotend, and the temp at which the safeties will cut in to shut things down.
Here we define the logic and connections for the endstops: all require pullup resistors and are inverted signals.
This is indicating that we have endstops for Y and Z in the minimum positions, and for X in the maximum position.
This sets the X-axis motors to run in the opposite direction to the other two axes’, and also notes that when homing, the X-axis needs to move towards its max position, not minimum as the Y and Z axes do.
Here we turn on the re-test capabilities for the Z axis as well as X and Y. This is the behavior that makes the head hit the end stops, bounce off, and then move back again more slowly. We don’t need the ‘back on home’ capability that moves the head away from the endstop after homing, so that is turned off.
I set the firmware to always honor the endstops, rather than only using them when homing. This avoids the situation that I’ve already run into too many times where you accidentally slam the head at full speed into the end stops when steering it manually in Repetier, and getting the direction wrong. With this, it will stop the attempted movement as soon as the end stop is hit.
Here we define the total bed size. This is especially important for the x-axis, since the head home to the maximum position: if the size defined here is wrong, then your prints won’t be positioned correctly on the bed. You can check the size of your bed by homing the head using Repetier Host, and then jogging the head until it goes as far as it can in each direction. Be careful as you get towards the ends – the head – and especially the fan – can catch on parts of the frame. i found this was especially true for the X-axis. These values are for my RXL; the Revolution will be smaller, of course, but I’m unsure of the exact size.
This sets all the steppers to 16x microstepping – but I think it isn’t used for the QU-BD printers; those have the microstepping set via jumper connectors on the board, I believe.
This sets the idle timeout on the motors. After a minute, the motors are released so that you can move the head around easily by hand.
This sets the maximum movement speed for each axis, and also the speed at which the head homes. Z-backlash compensation isn’t used on the RXL.
This sets the acceleration for each axis. QU-BD specified 5000 in their source code, and have it the same for print and travel moves. You can potentially override this in Slic3r, although some users have reported issues setting it as high as 9000; you might even want to go lower, to say 3000 if you have any problems with steps skipping.
QU-BD sets the jerk setting to 40 for the X and Y axes. This is the maximum velocity change at a corner (not really jerk as properly defined in mechanics – i.e., the rate of change of acceleration). Since I compiled my firmware, I’ve actually used the Viki controller to lower this to 25 on my printer; this helps to reduce the shaking that happens on fast, short, infill print sections.
This defines the number of print moves that are buffered in the firmware; a larger number reduces the likelihood of the queue emptying during intricate sections of fast, short line segments. However, it also reduces the responsiveness of the printer to real-time tuning via LCD or USB connections, since all the buffered moves will need to be completed before any changes are processed.
250000 is the usual baudrate that is used. Some Linuxes may require 115200, in which case it needs to be set in the firmware and in Repetier or any other control software that you use to connect to the printer.
The purpose of this code is to provide defaults, in the event that the hardware-specific code doesn’t set these SD-card-related variables. However, I found this tended to conflict with the definitions for the X3 and Viki systems, so I commented all of this out to make sure it can never override those changes. This might not be needed however, but it works, so I left it that way for my own code.
Since there is no print cooling fan, we don’t need to enable that stuff.
This selects the Viki as the control interface. If you have no LCD controller, or a different one, change this value accordingly. (In later versions of my code, this is done with the QU-BD specific macros, discussed above).
Here we set the language to use – English in my case – and also define a custom version string, so I can track whether my custom firmware really got loaded.
I found that the default speed was a bit too fast on my Viki panel, so I reduced the encoder sensitivity, to make it a bit easier to control.
This is where you can define the temperatures that you want to set when you choose the ‘Preheat PLA’ or ‘Preheat ABS’ option in the LCD control system. It also allows you to specify the range of temperatures and speeds that the UI will allow you to pick.
Wiring of the X Endstop
The QU-BD printers use a max endstop for the x-axis, rather than more normal minimum one that are used for the other two axes. However, it has been pointed out on the forums that some QU-BD printers – possibly all of them except the very earliest RXL’s – connect the X stop as if it was a minimum endstop. According to the standard wiring of an X3, it should be jumpered onto the pins behind the terminal blocks that are reserved for the minimum endstops. Instead, it is screwed directly into those terminal blocks.
The photo shows the x endstop connected to the ‘correct’ place (for orientation, the green terminal blocks pictured are on the edge of the Azteeg board, adjacent to the power supply on the RXL). Most likely , unless your printer is an early RXL, it will be screwed into the terminal block, alongside the Y and Z end stops. In this case, you need to include the following lines in your Configuration.h file:
#define X_MIN_PIN 2 #define X_MAX_PIN 3
This needs to go somewhere after the #include “pins.h” directive towards the top of the file.
If you’re using my version from github, you can just uncomment the QU-BD_CROSSED_XSTOP definition line at the start of the file to have this happen automatically.