›

0.92.3 Ultimaker-Smartcontroller Combo not Functional

WildseyedWildseyed
in Repetier-Firmware
I did a sanity check on a GT2560 (Ultimaker 1.5.7 Compatible) and Smartcontroller LCD 2004 using the Arduino Example LCD Display sketch, using the following pins, and it worked fine.
LiquidCrystal lcd(LCD_RS, LCD_EN, LCD_D4, LCD_D5, LCD_D6, LCD_D7);
LiquidCrystal lcd(20, 17, 16, 21, 5, 6);

The 0.92.3 Firmware configuration tool produces source with different values for these pins, but even after changing to the correct values, there is no display. The buzzer and Click Encoder pins are also not matched, but I cannot test that without display.

My guess is that some defines are overriding since I have not selected RAMPS or RUMBA. Is it the case that these two boards are the only ones supported?

Comments

  • RepetierRepetier
    What display did you select? I don't think any display has preset lcd settings for ultimaker, so you need to set them as manual configuration instead. Or modify in ui.h one similar display to use the right pin numbers and select that one.

    Config tool does not set any of these pins. If you use a predefined display that is known for that board it has preset pins.
  • WildseyedWildseyed
    Yes, I came to the same conclusion after examining the source.  The thing is, I did modify uiconfig.h and pins.h, using Marlin pin assignments, and information found on the Ultimaker Shield wiki, but I got only a screen full of a single character (Japanese).  After this is when I loaded up the LCD demo code from Arduino IDE, just to double check. It did work there.

    If I understand you correctly, there might be additional things to change in ui.h
  • RepetierRepetier
    Not regarding LCD except charset and timing. You can also use the liquid crystal library instead of the faster build in lcd library. Just make sure for the buildin to use the 4 bit parallel version and it normally works well. And most important set FEATURE_CONTROLLER to use uiconfig.h
  • WildseyedWildseyed
    Added the following in ui.h.

    It workds, mostly. SD card is always detected, even when removed. The display is a bit glitchy here and there. Any ideas on the glitch? I don't see this in Marlin, even with longer cables. 

    #elif MOTHERBOARD == 37 // ULTIMAKER_157, GT2560 

    #define BEEPER_PIN             18
    #define UI_DISPLAY_RS_PIN      20
    #define UI_DISPLAY_RW_PIN      -1
    #define UI_DISPLAY_ENABLE_PIN  17
    #define UI_DISPLAY_D0_PIN      16
    #define UI_DISPLAY_D1_PIN      21
    #define UI_DISPLAY_D2_PIN      5
    #define UI_DISPLAY_D3_PIN      6
    #define UI_DISPLAY_D4_PIN      16
    #define UI_DISPLAY_D5_PIN      21
    #define UI_DISPLAY_D6_PIN      5
    #define UI_DISPLAY_D7_PIN      6
    #define UI_ENCODER_A           40
    #define UI_ENCODER_B           42
    #define UI_ENCODER_CLICK       19
    #define UI_RESET_PIN           41
    #undef SDCARDDETECT
    #define SDCARDDETECT           38
    #undef SDCARDDETECTINVERTED
    #define SDCARDDETECTINVERTED   0
    #undef SDSUPPORT
    #define SDSUPPORT              1

  • RepetierRepetier
    You could check in ui.cpp

    void lcdWriteByte(uint8_t c,uint8_t rs)
    {
    #if false && UI_DISPLAY_RW_PIN >= 0 // not really needed
        SET_INPUT(UI_DISPLAY_D4_PIN);
        SET_INPUT(UI_DISPLAY_D5_PIN);
        SET_INPUT(UI_DISPLAY_D6_PIN);
        SET_INPUT(UI_DISPLAY_D7_PIN);
        WRITE(UI_DISPLAY_RW_PIN, HIGH);
        WRITE(UI_DISPLAY_RS_PIN, LOW);
        uint8_t busy;
        do
        {
            WRITE(UI_DISPLAY_ENABLE_PIN, HIGH);
            DELAY1MICROSECOND;
            busy = READ(UI_DISPLAY_D7_PIN);
            WRITE(UI_DISPLAY_ENABLE_PIN, LOW);
            DELAY2MICROSECOND;

            WRITE(UI_DISPLAY_ENABLE_PIN, HIGH);
            DELAY2MICROSECOND;

            WRITE(UI_DISPLAY_ENABLE_PIN, LOW);
            DELAY2MICROSECOND;

        }
        while (busy);
        SET_OUTPUT(UI_DISPLAY_D4_PIN);
        SET_OUTPUT(UI_DISPLAY_D5_PIN);
        SET_OUTPUT(UI_DISPLAY_D6_PIN);
        SET_OUTPUT(UI_DISPLAY_D7_PIN);
        WRITE(UI_DISPLAY_RW_PIN, LOW);
        WRITE(UI_DISPLAY_RS_PIN, rs);

        WRITE(UI_DISPLAY_D4_PIN, c & 0x10);
        WRITE(UI_DISPLAY_D5_PIN, c & 0x20);
        WRITE(UI_DISPLAY_D6_PIN, c & 0x40);
        WRITE(UI_DISPLAY_D7_PIN, c & 0x80);
    #if FEATURE_CONTROLLER == CONTROLLER_RADDS
        HAL::delayMicroseconds(10);
        HAL::delayMicroseconds(2);
        WRITE(UI_DISPLAY_ENABLE_PIN, HIGH);   // enable pulse must be >450ns
    #if FEATURE_CONTROLLER == CONTROLLER_RADDS
        HAL::delayMicroseconds(10);
        HAL::delayMicroseconds(2);
        WRITE(UI_DISPLAY_ENABLE_PIN, LOW);
    HAL::delayMicroseconds(100); // add this line
        WRITE(UI_DISPLAY_D4_PIN, c & 0x01);
        WRITE(UI_DISPLAY_D5_PIN, c & 0x02);
        WRITE(UI_DISPLAY_D6_PIN, c & 0x04);
        WRITE(UI_DISPLAY_D7_PIN, c & 0x08);
        HAL::delayMicroseconds(2);
        WRITE(UI_DISPLAY_ENABLE_PIN, HIGH);   // enable pulse must be >450ns
        HAL::delayMicroseconds(2);
        WRITE(UI_DISPLAY_ENABLE_PIN, LOW);
        HAL::delayMicroseconds(100);
    }

    and add 
    HAL::delayMicroseconds(100); // add this line
    as indicate din source. This is how liquid crystal would do it also that extra paus eis normally not needed. But this routine is it which sends data to lcd so if there is a problem it will be in this function and it can only be timing. 
Sign In or Register to comment.