lcd dosent work with ramps 1.4

Shop Forum Makelangelo Polargraph Art Robot lcd dosent work with ramps 1.4

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
  • #25389

    Hello everybody i’ve just built my first polograph machine followign this instructable using the ramps 1.4 i’ve just uploaded the firmware to the board and i can controll it with the makelangelo software but the problem is that when i plug the lcd it dosen’t work i just get a blue screen and i’ve uploaded the same firrware as the instructable i have a reprap 12864 lcd does anyobdy knows how i can solve this problem thanks and i’m a beginner on this like said i’ve just finished building it today


    The instructable firmware instructions are probably out of date. Try this:


    i did that, with no luck lcd still blank


    According to this thread
    Everything should be the same but one of the connector is physically rotated 180 degrees.
    Does that make sense? It could just be you have a cable backwards.


    Solved !!! Thats how it works

    In BOARD RAMPS .H changing

    // LCD pins
    #ifdef LCD_IS_128X64
    // 128×64 full graphics controller
    #define BEEPER 37

    //#define LCD_PINS_RS 19
    //#define LCD_PINS_ENABLE 42
    //#define LCD_PINS_D4 18
    // these alternate pins might help – see
    #define LCD_PINS_RS 16
    #define LCD_PINS_ENABLE 17
    #define LCD_PINS_D4 23

    #define LCD_PINS_D5 25
    #define LCD_PINS_D6 27
    #define LCD_PINS_D7 29

    // Encoder rotation values
    #define BTN_EN1 31
    #define BTN_EN2 33
    #define BTN_ENC 35

    // SD card settings
    #define SDPOWER -1
    #define SDSS 53
    #define SDCARDDETECT 49


    In CONFIGURE.H changing

    // LCD panels supported

    #define HAS_LCD // if you have an LCD panel
    #define HAS_SD // if you have SD card support on your LCD panel (must be on panel?)

    // only uncomment one of these options
    #define LCD_IS_128X64 // reprapdiscount Full Graphic Smart LCD Controller
    //#define LCD_IS_SMART // reprapdiscount Smart LCD Controller (including XXL model)



    I have added your pin number changes to makelangelo-firmware dev branch. Can you confirm I got it right?



    Thanks a lot… This solved my problem with Mega+RAMPS &Full Graphic controller


    I have modified code to use interrupts for 12864 LCD and RAMPS 1.4. Encoder works nicely now. How do I submit it for a PR so you can review it? I can’t push a new branch to the github repo.


    did you branch from the main repository? You should be able to submit a PR with either github desktop or through the github website. I haven’t contributed to many other projects so I’m not confident enough to guide you. Come to our Discord if you need more help or to chat live about development.

    Tylor Koenigsfeld

    Which LCD are you using? When I turn my dial, nothing updates on the screen. I have to mess with it for a couple minutes for it to finally move a little bit. Also It would seem the SD card pins are incorrect as well for my LCD. I can detect my SD card using a different arduino program with the following code, im not sure how to adopt it for makelangelo.

    const int chipSelect = 53;    
    #include <SD.h>
    Sd2Card card;
    SdVolume volume;
    SdFile root;
    void setup() {
      Serial.print("\nInitializing SD card...");
      pinMode(53, OUTPUT);
      pinMode(48, OUTPUT);  
      pinMode(SPI_MISO_PIN, INPUT);
      pinMode(SPI_MOSI_PIN, OUTPUT);
      pinMode(SPI_SCK_PIN, OUTPUT);
    void loop () {
       if (!card.init(SPI_FULL_SPEED, chipSelect)) {
        Serial.println("initialization failed. Things to check:");
        Serial.println("* is a card is inserted?");
        Serial.println("* Is your wiring correct?");
        Serial.println("* did you change the chipSelect pin to match your shield or module?");
      } else {
       Serial.println("Wiring is correct and a card is present.");
      // print the type of card
      Serial.print("\nCard type: ");
      switch(card.type()) {
        case SD_CARD_TYPE_SD1:
        case SD_CARD_TYPE_SD2:
        case SD_CARD_TYPE_SDHC:
      // Now we will try to open the 'volume'/'partition' - it should be FAT16 or FAT32
      if (!volume.init(card)) {
        Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
      // print the type and size of the first FAT-type volume
      long volumesize;
      Serial.print("\nVolume type is FAT");
      Serial.println(volume.fatType(), DEC);
      volumesize = volume.blocksPerCluster();    // clusters are collections of blocks
      volumesize *= volume.clusterCount();       // we'll have a lot of clusters
      volumesize *= 512;                            // SD card blocks are always 512 bytes
      Serial.print("Volume size (bytes): ");
      Serial.print("Volume size (Kbytes): ");
      volumesize /= 1024;
      Serial.print("Volume size (Mbytes): ");
      volumesize /= 1024;
      Serial.println("\nFiles found on the card (name, date and size in bytes): ");
      // list all files in the card with date and size | LS_DATE | LS_SIZE);
      delay (3000);

    From the code you posted it looks like chip select is pin 53 (matches board_ramps.h) and sd card detect is 48 (board_ramps.h has 49 as the default). Look for

    #if LCD_TYPE == LCD_IS_128X64 

    in the code. I don’t have a 128×64 screen so I can’t test it locally.

    At the top of your code there’s an “const int chipSelect = 53;” and later the number 53 is used many times instead of the word chipSelect, which is the point of having chipSelect. in I would use a

    #define CHIP_SELECT 53

    and then use the world CHIP_SELECT instead of ’53’ where appropriate. The pre-processing step of the compiler will replace the word with the equivalent number. it’s probably better than ‘const int’ because a const int might take up some ram if the compiler is dumb, and ram in an arduino is in short supply. also if it actually takes up ram then the firmware has to look up that number every time it is used, which is slower than having the number hard coded on hand ready to go.

    48 should have been been done the same way. The point of defines like that is so that only one place has to be changed to update all the code.


    I know how to use git, but not really familiar with github. That said, I found instructions on stackoverflow about how to use github. Seems they want me to make a forked repo instead of just branching in your repo. I believe the pull request has been made. Here’s the steps I found…

    • click fork button on original github project page
    • clone your forked repository instead original
    • push to it
    • press Pull Requests button on your repository
    • create it
    • wait for original author to accept it

    I had started from your Dec 23 commit with hash ca06a9ca702, but the repo was updated today, so I had to merge my changes into that. A fix for the “print from file” menu that I made today (lcd_dirty flag usage) that is unrelated to the encoder interrupts unfortunately got committed with it when I merged the code. The commit message explains what I did, and I’ll quote it below too.

    Implement interrupts for 12864 LCD encoder with RAMPS 1.4 configuration

    A configuration item named USING_12864_WITH_ENCODER_INTERRUPTS
    was added to the board_ramps.h include file to enable interrupt usage.

    These changes require adding a jumper from D33 to D18, and one from
    D31 to D19. These can be done from the display connector to pins on
    the RAMPS 1.4 board. I cut a female jumper cable in half, soldered
    the wire to the display adapter, and used the female end to attach to
    the correct pin on the RAMPS 1.4 board.

    D33 and D31 will still be set to inputs and receive the signal, but
    they are not used. Interrupts are enabled for D18 and D19, their
    pull-ups are enabled, and the signal is read from the new pins.

    Code was written to process the interrupts and handle menus. Turning
    the knob quicker will increment float and long values quicker.

    The button press was not moved to an interrupt. It still must be held
    sufficiently long for the polling code to recognize the button press.


    Tylor, I’m using a 12864 LCD and RAMPS 1.4 and ran into the same issue where the knob/menus were unusable. So the first thing I did was fix that so I could explore the menus.

    I have these settings to get the display to work (obviously your display already works too):

    #define LCD_TYPE LCD_IS_128X64


    #define LCD_PINS_RS 16
    #define LCD_PINS_ENABLE 17
    #define LCD_PINS_D4 23

    And then I jumpered pins 33 and 31 to inputs that have interrupts (18 and 19) and modified to the code to work with interrupts.

    My SD on the 12864 worked, but there was an issue where it wouldn’t display the file names. I accidentally submitted that fix with the interrupt code PR.

    Tylor Koenigsfeld


    I did the hardware bypass and got pins 33 and 31 mapped to 18 and 19. I changed my code to say the following

    // Encoder rotation values
    #define BTN_EN1            19
    #define BTN_EN2            18
    #define BTN_ENC            35

    Is there something else you modified in the code? My dials and buttons seem to work about as badly as before. Thanks for the reply.


    Yes, the “modified to the code to work with interrupts” requires some changes that would be a bit extensive to list here… and there some jumpers that would be needed too. Dan is concerned about using the interrupts and what affect that could have on motor control. I believe I could point you to the github fork I made, but probably worth waiting for Dan to look it over first since he knows the code base.


    I like (and made a few comments on) your PR 🙂


    Provided some responses in the PR, and put a picture to show the jumpers I had to do. Let me know your thoughts about the stepper motor and servo verse interrupts, and if something different is warranted (e.g. disabling the knob interrupts during time critical sections).


    Dan, pushed changes to use abs() when turning the knob quickly per your PR comment. Also fixed some code that could overwrite and corrupt memory, made long M117 messages wrap on the 128×64 display so they can be read, and fixed a display location calculation error that made the 128×64’s left most column not get used. Those changes are pushed to my fork in github and can be viewed in the PR.

Viewing 18 posts - 1 through 18 (of 18 total)
  • You must be logged in to reply to this topic.