Introduction: Reprap Full Graphic Smart Discount Controller

About: I like to improve myself and things I find :) Learning new things every day is next to impossible but I still try - only a working brain can work. I have no special sector to cover, electronics, electrical stu…

Some people like to get more control about their projects and instead of just a tiny status display something bigger is welcome.
The Smart Discount Controller comes in several variations, which are basically just different display sizes and shield layouts.
However, unlike all the ads the controller seems to be very tricky for some users.
In this little Instructable I will try to address some of the worst issues and suggest some possible solutions to get the controller working as advertised.

Image taken from the official Raprap website for this controller.
I used the original image as my controller is a china knockoff and already looks quite butchered after the mods and experiments.
If you want to avoid problems get a controller that is conform to the above!

Step 1: The Good and the Bad Things

Let's start with all the Pro's:
The controller is quite well designed for the purpose of providing a big display, a fully featured SD reader (SDHC of 32GB are no problem) and a little encoder knob to go through your menus and settings.
Overall build quality on mine was very good with nothing to complain although some people noticed bad soldering points in some areas.
There is also a little buzzer that can be used for acustic feedback on selections or as a warning device.
Connection depends on the model and type you select.
In my case it came with two ribbon cables and a bracket for the RAMPS shield.
Other variation include a direct connection for the Arduino pins in the form of a complete shield or just short cables with pin headers.
There is also a "naked" version available on Ebay that only offers a pin header for soldering but no cables at all.
So enough for every purpose.

The con's so far:
One of the worst problems is missing documentation.
You either have to find a supplier that sticks close to the original Reprap design or you will face some more or less noticable diffences.
For most users the frustration starts with nothing.
LOL Nothing in the term of the display having no usable contrast so it appears either off or with a blank screen and the backlicht on.
One of these nothings is related to a faulty connection, if your backlight is off and there is no beep when you press the encoder then switch the two ribbon cables ;)
The other case only affects about 50% of the users and is cause by either the wrong contrast level of a missing 5V supply to the controller.
But by far the worst problem seems to affect users with a Ramps shield and using this controller.
The SD will be recognised when inserted but the menu or sketch will claim there is no SD or that it is empty.
This can have several causes including the missing 5V supply for the controller.

Step 2: Possible Fixes That Worked for Me

Let's start with the basics, shall we?
I assume you either have a 3D printer you want to upgrade or that your project reqiures a decent display.
As stated in every example sketch for these displays you will need the U8GLIB library for your Arduino ISP.
You also need the SPI and SD libraries.
Code wise you should be covered by studying the documentation for these libraries.
That was only to make sure you have included what you need for this controller.
For Marlin firmwares you only need to uncomment the DEFINE for this controller in the configuration.h file.

The display does not seem to work...
Check if you have 5V on all Arduino 5V pins!
In my case the modified RAMPS shield no longer suppied the voltage for the Arduino and I had to add a voltage regulator to power the Arduino independent from the Ramps shield.
Without that the 5V supply for the display controller will only reach 3.2-3.6V instead of the 5V required.
Still no luck?
There is a potentiometer on the controller, on some models it is to adjust the contrast level of the display, on most it is just useless, so try if turning changes the contrast.
Again nothing?
Now you will hate me ;)
There is another potentiometer directly on the back of the actual display.
With this the contrast can be adjusted independent from everything.
But before you try here make sure all is connected correctly and that you have 5V!
I found two way of adjusting this pot.
a) Using wooden skewer and trying to use a corner of the dial for the adjustment by pushing - not very easy, not very accurate and very easy to break the poteniometer.
b) Unsoldering the display from the board and using ribbon cable so you can adjust the level on the go.
Works fine but is a pain to do and might only be worth it if you would prefer to seperate the display as otherwise you need to revert those changes.
This potentiometer is very sensitive and there is only a little "sweet spot" where you get something to see on the display.
Too much and all is black, too little and it looks like only the backlight is on.

The encoder is not working properly...
It can be tricky to get the encoder working as planned.
For Marlin you can try different values for the encoder steps and clicks.
For your own projects based on the example codes you do the same.
If the direction is reversed you can simply switch the pins for the encoder ;)

SD problems....
After fixing all the above or being lucky enough to get a model that worked out of the box you might still use very bad language while trying to use a SD with it.
And trust me, I did exactly the same for more than just a few hours LOL
As mentioned earlier the main culprit here is the 5V supply as without it the 3.3V regulator for the SD card won't work.
But for some reason this controller is also very picky in terms of supporting all SD cards you put in!
So if you have problems with the SD check the 5V first, then use the sample sketch "CardInfo" from the SD library to check if you have SD cards that work.
To do so:
Check the sketch that the right pins are used!
Usually the ICSP connection is used here and depending on the type of Arduino pins 4, 8, 10 or 53 (for the Mega with RAMPS) is used to detect the SD card.
Some people might think using pin 49 (on the Mega) for the SD detect is a good thing.
It works as this would be the pysical switch for it but it also masks any problem with the library or SD.
When you uploaded the sketch start the serial monitor and you should get a little status info telling you no SD is present and to check some things.
Close the serial monitor window and insert a SD card, open the serial monitor again and check if the card is recognised.
If in doubt format the SD with the format tool provided by SDCARD.ORG - it will format any SD to the manufactures specs, Windows format is not suited for this task.
There is a good chance your first SD won't work, so keep a few at hand for testing.
My trusted 2GB card works in all old devices but not in this SD reader, my 32GB SHD works just fine - go figure...
Did I mention to check the pin assignments? So if several cards in a row refuse to work check if you really use the right pins in the sketch, especially for the Mega2560!
Ok, the card is recognised when you push it in but you can't see any files or even the FAT info.
Assuming you made sure the pins are really correct you should now try a SD library from a different IDE version.
I still prefer the 1.05 for all my projects.
Keep in mind that when you change things in the library folder that you need to close all IDE windows and reload the IDE as otherwise nothing will change.
Now everything should work and you should able to find at least one SD in your collection that works.
If you can see the type of SD in CardInfo, like SD, SDHC and such it means the communication works sort of but most importantly that this SD is supported.
Properly formatted but still no visible files on it can mean your SD library need some changes.
In SD.H file search for

boolean begin(uint8_t csPin = SD_CHIP_SELECT_PIN);

and replace with:

boolean begin(uint8_t csPin = SD_CHIP_SELECT_PIN, uint8_t spiSpeed = SPI_HALF_SPEED);

In SD.CPP search for

boolean SDClass::begin(uint8_t csPin) {

Performs the initialisation required by the sdfatlib library.

Return true if initialization succeeds, false otherwise.

*/ return card.init(SPI_HALF_SPEED, csPin) && volume.init(card) && root.openRoot(volume);

and replace with:

boolean SDClass::begin(uint8_t csPin, uint8_t spiSpeed) {

Performs the initialisation required by the sdfatlib library.

Return true if initialization succeeds, false otherwise.

*/ return card.init(spiSpeed, csPin) && volume.init(card) && root.openRoot(volume);

This will give more transfer speed options for the serial communication.
After this last resort mod all should work just fine.

Step 3: Things Suggested in Other Places That Might Work But Mostly Waste Time

Checking for bad solder points can be done of course but with modern and automated productions chances are that all is fine here anyway.
A lot of clever people claim that all their problems disappeared once they used very short cables instead of the 30cm standard ones supplied.
I only see the cable length as a problem in a very EM noisy enviroment as on most older computers ther serial connections for external brackets, mouse and keyboard have often been even longer.
The standard serial com here only uses 9600baud anyway.
By far the worst "fix" I read about was in regards to the missing 5V with some shields used.
In the author's case it worked fine as the corresponding 5V pin on his shield was not connected to the Arduino.
The fix here was to simply take the 5V from elsewhere and to bridge it onto the controller pins.
If you need to do something like this use a 5V pin from the Arduino and also a ground line from it for the negative connection!
A possible disaster waiting to happen was the suggestion to get access to the hiddin potentiometer by simply bending the display up on the pin header.
In most if not all cases this well break something before get enough clearance to reach this pot properly - soldering the display off and using a ribbon cable is the only way here.
Warranty replacements might sound like the right way to go when nothing works but chances are you get the same model back and you face the same problems again.

Step 4: How to Test If Really Nothing Seems to Work

In some cases you will have a ready to go program but it just won't work as downloaded.
Take Marlin for a 3D printer as an example.
Now you want to figure out if all components of the controller work or not.

1. Grab some sample sketches and test encoder, display and SD functions seperately.
2. Make sure that you really use the right pins on your Arduino!
Especially the SD detect, SDSS needs to be at the right pin to work, so double check the sketch here.
3. If in doubt don't use the latest IDE release, the 1.05 works just fine for most of everything.
4. The values for the serial communtion should be at 9600buad, don't confuse them with the connection speed of USB and Arduino!
5.Once you have one feature tested an working note down the pins used and the settings for reference in your actual project.
With a lot of testing it is only too easy to confuse yourself and you might not remember everything when finnished ;)
6. Your worst nightmare might be the SD itself, so if in doubt try bigger sizes than 4GB and don't expect that any old card below 4GB will work!

Step 5: How Does That Thing Actually Work and What Else Is Possible?

Let's sum up the features:
1. Encoder: Simple thing that uses a few digital pins to give you a push button and directional steps while turning.
2. SD card reader: Uses the ICSP connection or a dedicated serial connection on Arduinios with enough capabilities to provide them.
3. Beeper: Nothing special really, just a beeper like used in so many breakboard experiments.
4. Display: Uses a simple serial connection, U8GLIB library required.

Apart from seperating the display there are not too many usable mods I could think of.
And since all display connection are available on the header of the controller board the disassably is only worth to get access to the hidden pot for relocation.
But as a seperate piece the display can be controlled in brigthness through a PWM signal and the constrast can be set through software.
Another plus is the option to use the included pins for a pralle connection - requires the library for the display though.
Refresh rates over the serial connection are ggod enough for status updates and such, with the parallel connection it would be fast enough for simple games like Pong or space invaders - the encoder can be used to control the pad while playing ;)
Considering that you can get the complete controller often for less than just the display it is always worth getting it all to play with ;)
The best use I could come up with so far would be a fully automated weather station.
Small UNO outside on solar power with sensors for all you need and a little tensponder to send the data every 10 or 20 secs.
Bigger Arduino with the complete controller for remote access and nice looking graphics for all data.
Data storage on SD to get a nice history graph over the day/month/year.
All I am waiting for is that my 20$ one fails but after almost 10 years it shows what I need LOL