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).

QU-BD-specific Macros

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.

QU-BD-specific macros

Configuring Repetier Firmware for the QU-BD RXL Printer

2013-11-11_14-37-23

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).

 

2013-11-11_14-38-21

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.

 

2013-11-11_14-38-49

Similarly, we set the steps-per-mm for the extruder motor.

 

2013-11-11_14-39-11

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.

 

2013-11-11_14-40-19

This defines the control logic for the extruder – basically whether the motor needs to turn clockwise or anti-clockwise for ‘forward’ movements.

 

2013-11-11_14-39-33

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.

 

2013-11-11_14-40-51

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.

 

2013-11-11_14-41-53

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?

 

2013-11-11_14-43-11

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.

 

2013-11-11_14-44-09

These set the range for the thermistor table, above.

 

2013-11-11_14-44-34

This sets the maximum allowed temp for the heated bed.

 

2013-11-11_14-45-00

This is taken directly from QU-BD’s code. Honestly not sure what it does. :-)

 

2013-11-11_14-45-32

This sets the maximum operating temp for the hotend, and the temp at which the safeties will cut in to shut things down.

 

2013-11-11_14-46-51

Here we define the logic and connections for the endstops: all require pullup resistors and are inverted signals.

 

2013-11-11_14-47-14

This is indicating that we have endstops for Y and Z in the minimum positions, and for X in the maximum position.

 

2013-11-11_14-48-03

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.

 

2013-11-11_14-48-50

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.

 

2013-11-11_14-49-09

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.

 

2013-11-17_23-57-55

 

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.

 

2013-11-11_14-49-34

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.

 

2013-11-11_14-49-58

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.

 

2013-11-11_14-50-24

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.

 

2013-11-11_14-50-43

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.

 

2013-11-11_14-51-06

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.

 

2013-11-11_14-51-25

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.

 

2013-11-11_14-51-48

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.

 

2013-11-11_14-53-20

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. :-)

 

2013-11-11_14-53-45

Since there is no print cooling fan, we don’t need to enable that stuff.

 

2013-11-11_14-53-58

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).

 

2013-11-11_14-54-18

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.

 

2013-11-11_14-54-46

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.

 

2013-11-11_14-55-21

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.

Endstop wiring

 

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.

 

Tagged with →  

12 Responses to QU-BD RXL: Repetier Firmware Settings

  1. Dennis says:

    Hi,
    I just spent a few hours going through your changes and trying to understand the Repetier software. When I first received the RXL printer I didn’t do anything with the configuration.h settings because I didn’t think I needed too. Using the Adrino software I updated the firmware using your configuration.h changes except I disabled for the Viki panel because I had an issue where under the Manual Control in Repetier there were commands that wanted to be sent to the printer. Only way they would clear is if I did Run Job even though I wasn’t doing a print. Even after doing that the commands would come back. Once I made the one change to disable the Viki the issue went away.
    I have another issue that I haven’t figured out yet. I can Home in both the Y and Z axis but it won’t home in the x axis. Every time I hit the x home axis button the head moves to the left about 10mm. I can get it to go to the right toward the x axis switch but not all the way. What could that be?
    I even loaded the QU-BD RXL firmware to see if it would make a difference, but no change.
    I have another question: I’m ok with making tweaks and doing upgrades to the printer, but in your opinion do you think the build quality is good and there is potential for the RXL printer? What I mean by that is even if we make software tweaks or extruder tweaks or other updates do you think the build design is good? You have a lot of experience with 3D printers and I would think you would be able to get good prints after some tweaks. Your last comment to me was that you have only been able to get one good print from this printer so far. In your opinion if you had it to do all over again would you buy the RXL printer knowing what you know now?
    Thanks for you help and advice.
    Dennis

  2. illuminarti says:

    Thanks for the feedback. Specifically what did you change to disable the Viki – just changing the feature_controller line back to 0?

    Regarding the x-homing. Has it ever worked? My guess would be that the switch is flaky, and keeps being triggered incorrectly. You could try using Repetier to issue some M119 commands and see what it reports for the endstop status. I think the movement to the left might be the homing ‘bounce’ that perhaps never completes because it never thinks it left the home position.

    I think the printer design is mechanically good in terms of the frame and drive system. I don’t like the finish details, such as the brackets, end switches etc. They seem less well thought out, and not strong enough, and the decision to glue so many of the parts together seems very strange. I’ve had to replace, rewire and redesign a bunch of stuff, and it still doesn’t work for me. The extruder just seems flaky, to be honest, although I’m researching to try and understand if anything can be done short of installing a totally new extruder system. I still have only gotten one good print on it – and while that was a very nice ABS print, it’s not something that I couldn’t have done on plenty of other printers in terms of speed or quality.

    I have three 3D printers now – an Original Ultimaker, Ultimaker², and the RXL. If you want a printer to tinker with, the original UM is a better choice, since its designed to be user-serviced and adjusted, and isn’t glued together. However, as a rule, my original UM doesn’t actually need tinkering with. It’s rock solid and prints great. I’m still just getting to grips with the UM2; it has a lot of potential, but had some teething problems of its own as they’re scrambling to keep up with much higher than expected demand. But the issues with that aren’t on the scale of the problems with the RXL, and the support community is excellent (if I do say so myself) and the company is quite mature and mostly does a better job of communication and support (although again, the UM2 launch has been a strain). Mostly I just need to learn the UM2 – I’ve only had it a couple of days.

    I haven’t given up on the RXL yet, but I think I’m already beyond the ‘few tweaks’ stage, and it’s still not really properly functional. Simply giving up would probably be a wiser course of action, but I keep trying to find a fix, because I desperately want it to be a good printer. :-)

    • Djkrump says:

      Sorry I didn’t see your post. I usually knew if there was a response when I received an email notification.
      Worked fine until now.
      I will try your suggestion in Repetier.
      Thanks.

  3. Djkrump says:

    To answer your other question.
    Yes, all I changed was the feature controller back to 0

  4. Constantine says:

    I am having the same issues as Dennis. I loaded your configuration.h firmware via Arduino, and I was immediately unable to manually control any of the printer functions. I do not have Viki, so I disabled it, switching the feature_controller line back to 0

    My X used to work, but it no longer operates. Instead, it does the same thing that Dennis’ refers to (about 10mm movement away from home when the X home button is activated). Like Dennis, my Y and Z home buttons are working properly, as they were prior. Any ideas?

    Also, I wanted to thank you for the Z homing mod that you created. It is awesome!

    -Constantine

    • illuminarti says:

      If I remember correctly, the issue was that QU-BD changed the way they wire up the endstops, so that they started using the azteeg pins intended for the x-min endstop wiring as the x-max endstop and vice versa. So you need to change that in the firmware, or else the firmware thinks that the x-max endstop is permanently pressed.

      Ah, yes, looking back at my source code… in configuration.h, I added a #define for this – QUBD_CROSSED_XSTOP. You probably need to uncomment that. And then it will work right. (Or if it’s currently uncommented, add ‘//’ at the start to comment it out.

      Thanks, I’m glad that the z-homing mod is working well for you. :-)

  5. Constantine says:

    You’re awesome, Illuminarti. That worked perfectly for the X homing.

    I was having issues with my hot end only going to 170 C and taking 15 minutes to get there. I knew something was wrong, but it was my own fault. My EEPROM “Extr. 1 heat manager”. The options are 0-1, and I had 1 in place. Changing this value to 0 worked for me. Just wanted to give a heads up to anyone who encounters similar issues.

  6. Paul Modiano says:

    Thanks for all this great documentation, Simon.

    I am running into the same issue that Dennis ran into. I installed the Viki on my RXL as per your wonderful instructions. I then loaded your version of the firmware and the Viki came to life. The problem is now, when I attempt to home X, it moves forward about 10mm. Y and Z appear fine.

    I tried uncommenting the QUBD_CROSSED_OVER line but that doesn’t fix the problem. I do have an early RXL (#12). Any ideas of what I might try to fix this?

  7. illuminarti says:

    In the other cases i’ve heard of, the issue was that the x max endstop was plugged in directly alongside the other two (min) endstops, not on the row behind, as it was on mine.

    If yours is on the row behind, you shouldn’t need the QUBD_CROSSED_OVER line, and can comment that out.

    Other than that, the issue is that the firmware is reading the x endstop as permanently activated (i.e., open circuit). So check the wiring, and make sure that the x-endstop behave the same as the other two – check me on this, but from memory I think that they are closed circuit when not activated, and the contact breaks when the switch activates.

  8. Chris Coleman says:

    I am one of the Rare breed of QU-BD RPM owners and wanted to add my Viki to that – your guides have been massively helpful and I wanted to let you know. Right now I want to figure out a good source and way to add endstops, especially a hall effect for the z-axis (I just dont trust switches for the precision of the z axis.)
    Chris

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: