[Bugfix 2.0.x] rearm and RepRapDiscount Smart Controller

[Bergerac56]

This is perhaps a very simple and stupid question but I did not succeed to connect a RepRapDiscount Smart Controller to a RAMPS 1.4 associated with a REARM yet.
I tried various LCD options in configuration.h without success. I get only 2 lines full of squares.

With the same hardware setup but with a full graphic LCD (my normal configuration) I do not have any problems.

Moreover, when I try #define ULTRA_LCD I get a compilation error:

...compiling .pioenvs\LPC1768\src\src\libs\hex_print_routines.o
Marlin\src\lcd\ultralcd.cpp: In function 'void lcd_init()':
Marlin\src\lcd\ultralcd.cpp:5273:5: error: 'lcd_sd_status' was not declared in this scope
lcd_sd_status = 2; // UNKNOWN
^~~~~~~~~~~~~
Marlin\src\lcd\ultralcd.cpp:5273:5: note: suggested alternative: 'lcd_setstatus'
lcd_sd_status = 2; // UNKNOWN

^~~~~~~~~~~~~
lcd_setstatus
Marlin\src\lcd\ultralcd.cpp: In function 'void lcd_update()':
Marlin\src\lcd\ultralcd.cpp:5373:22: error: 'lcd_sd_status' was not declared in this scope
if (sd_status != lcd_sd_status && lcd_detected()) {
^~~~~~~~~~~~~
Marlin\src\lcd\ultralcd.cpp:5373:22: note: suggested alternative: 'lcd_setstatus'
if (sd_status != lcd_sd_status && lcd_detected()) {
^~~~~~~~~~~~~
lcd_setstatus
*** [.pioenvs\LPC1768\src\src\lcd\ultralcd.o] Error 1

Here is my config file (With option #define ULTRA_LCD uncommented)
Configuration.zip

[tcm0116]

The RepRapDiscount Smart Controller is not compatible with the ReArm without building a custom cable/adapter and modifying the pins file.

See here for more info.

[Bergerac56]

@tcm0116 Thanks Thomas. You pointed to the good direction. I will investigate that

[thinkyhead]

Has anyone built the cable and can provide photos / diagrams for the website?

[AnHardt]

That's the best i can find.

[thinkyhead]

That's the best i can find.

So, the same as linked above. Unfortunately that page states that it only applies to:

• Panucatt Devices Viki2 LCD
• Panucatt Devices mini Viki LCD
• RRD Full Graphic Smart LCD

…and for the "RRD Smart LCD, Viki1 LCD (and other non-SPI LCDs)" they link to https://github.com/wolfmanjm/universal-panel-adapter which is not very nicely illustrated. Does the wiring for the RRD Full Graphic Smart LCD apply just as well for the HD44780 2004 LCD?

[Bergerac56]

I putted a bit this project on hold. When I have 5 minutes, I will try to buil this cable and come back if some success

[thinkyhead]

Any guidance you can provide will be great. I can try to do the same with the ReARM I have here, but I need to dig up a spare RAMPS shield (or three). I'd like to post some clear instructions and good images on the marlinfw.org website for the common displays, and help the "Chris's Basement" YouTube channel do a followup to his Marlin 2.0 ReARM video.

[tcm0116]

#7390 discusses several options for connecting a 2004 LCD to the Re-ARM

[p3p]

#7390 (comment) is what I built to test with (thanks @tcm0116 I had no idea where I had posted them)

[tcm0116]

@p3p - I knew we talked about it somewhere, but it took like 30 minutes to find. Ha.

[Bergerac56]

@thinkyhead After a lot more than 5 minutes ;), here is a way to build a custom EXP1 cable for the REPRAP_DISCOUNT_SMART_CONTROLLER for the RE_ARM. It uses several pins on J3,J5 and J12

This version of the cable uses stricktly the standard "pins_RAMPS_RE_ARM.h" pins definition. EXP2 is connected to the RAMPS as usual. (just #define REPRAP_DISCOUNT_SMART_CONTROLLER)

As I use the SD card of the REARM (onboard) to print, I did not test the SDcard on the LCD. But I do not see why it should not work. (if somebody has time to test, doing the right adaptations in the config files...)

I also made another cable, easier to build but with a modified pin file. (and still some bad affectation of some pins to solve)

Is it what you was asking for ? (and sorry for the handmade schematic )

[thinkyhead]

Thanks! Those are helpful images. I’ll mock them up in Illustrator for the website and produce a page on this topic that hopefully makes everything super easy. Your super easy summary will help a lot.

[thinkyhead]

EDIT: Replaced the original image with updated one below.

[Bergerac56]

@thinkyhead Nice Scott :) The idea of putting colors is excellent

But there is a mistake (I think) in your "transcription". You take the 5V and GND on connector J12 (at the wrong pins) where I do it on J3. The graphics show the right wiring but not the text.

We could take +5v and GND on J12 but at pins 13 and 14. I found it easier to take it on J3

[Bergerac56]

@thinkyhead Hello Scott
I have reconsidered this subject and have made some corrections. You will find here an adapted/corrected picture of the connexions. I added also a description of how to make the cable and the specific connector. If you need the pictures at a larger size, just tell me.

As the spacing between J5 and J12 does not respect the 2.54mm standard, it is not possible to use one connector. We need to build an adapted one. It is obviously possible to use 3 distincts connectors as I did for the prototype but it is less nice ;)

How to build the connector :
1> From a 40x2 connector (easy to find on Amazon: https://www.amazon.com/uxcell-2-54mm-40-Pin-Female-Connector/dp/B00R1LLM1M/ref=sr_1_1?ie=UTF8&qid=1546626605&sr=8-1&keywords=40x2+connector) I cutted 2 « blocks » One of 10x2 pins and one of 8x2 pins. I removed the unneeded pins (see picture)

2> After some triming with a small piece of sand paper, the 2 « blocks » fit perfectly on the re-arm's J3,J5 and J12

3> It is time to glue the 2 blocks together in order to have one solid connector of 17x2 (plus a little bit of plastic to fit the outfit of J3,J5 & J12) The best way is to use the re-arm itselve as a support. BE CAREFULL not to glue the connector to the RE-ARM (You have been warned…)

4> Now, just solder the 10 wires of the flatcable following the schematic above.

And that's it :)

[Anycubic]

Hello @Bergerac56 , any hint on how to make the RRD SD card works? I can see the card on LCD menu but I can't browse the files (list is empty). Thanks!

[Bergerac56]

Hello @Anycubic
Sorry, I was not at home.

Basically, I do not use the "LCD" card reader. As the RE ARM is difficult to reach inside the printer case, I prefer to be able to access both the firmware and the gcode files through one channel. This is why I did not check the LCD card reader.

Just changing pin file from:
//#define USB_SD_DISABLED
#define USB_SD_ONBOARD // Provide the onboard SD card to the host as a USB mass storage device

//#define LPC_SD_LCD // Marlin uses the SD drive attached to the LCD Test TCD
#define LPC_SD_ONBOARD

to:
//#define USB_SD_DISABLED
//#define USB_SD_ONBOARD // Provide the onboard SD card to the host as a USB mass storage device

#define LPC_SD_LCD // Marlin uses the SD drive attached to the LCD Test TCD
//#define LPC_SD_ONBOARD

does not work for me too. I suppose there is a pin definition problem. I will look at it when I have time.

[Anycubic]

Hello @Bergerac56, I figured that out ;-) also HW SPI is not working with this board, I hope they will fix it as well in the future, thanks!

[Grogyan]

It is a good idea to not use the SD slot on the display, as the length of the ribbon cable is such that it can easily pick up any EMI.
The best option is to use the onboard SD for storing GCODE.

For those that don't want to keep unplugging it, you can use a SBC like a Raspberry PI to manage the onboard GCODES remotely. This is the method I use.

[Bergerac56]

@Anycubic You are right. I came to the same conclusion but... forgot to report it ;). It seems to be specific to the RE-ARM configuration. When I use a MKS-SBASE board (with custom cable obviously different than the cable of the RE-ARM) it works. And with a ribbon cable of 50 cm ;)

[Bob-the-Kuhn]

Firuring out how to use the LCD's SD card on Re-ARM is on my to do list. The signals all look good but it isn't working.

I use the onboard SD card for both gcode files and for firmware updates. With SDSUPPORT (only) enabled, the on board SD card is mapped to the PC as a drive after reset. In the host software, mounting the SD card makes the Gcode files available to the controller for printing but the mapped drive goes away. Unmounting the SD card makes the mapped drive come back.

[Bergerac56]

@Bob-the-Kuhn : I also use mainly the onboard card on my RE-ARM and MKS SBASE configurations.
But I do one more modification:
In menu_main.cpp, I modify 2 lines (175 & 256):
MENU_ITEM(gcode, MSG_CHANGE_SDCARD, PSTR("M21")); // SD-card changed by user
replaced by
MENU_ITEM(gcode, MSG_CHANGE_SDCARD, PSTR("M22")); // SD-card changed by user

So I can toggle easily between access from the PC and access from the LCD screen

[Anycubic]

Hello, I just used latest build and now I have garbage on the LCD screen when using "LPC_SD_ONBOARD" (LPC_SD_LCD not working yet). Of course still using RRD Smart controller. When I refresh the screen garbage disappears, if not moving the encoder garbage again. Anyone having same issue? SD support with Re Arm is a nightmare for me!

[robbycandra]

@Anycubic , will anycubic use ReArm in future product ?

[Anycubic]

I don't know, I just own a Anycubic Kossel Plus :-D

[Anycubic]

Actually I have garbage on the screen even if SDSUPPORT is disabled, so it seems to me RRD Smart Controller part was broken in the latest code version

[Bergerac56]

Unfortunately, I cannot test this for the moment. The printer with the RE-ARM is in another location

[Bob-the-Kuhn]

I just downloaded 2.0.x and was able to reproduce the problem. With both SDSUPPORT and LPC_SD_LCD enabled then acessing the LCD's SD card causes the display to garbage up and stay that way until clicking the encoder button.

Have you thought about using the Re-ARM's onboard SD card for gcode files? If just SDSUPPORT is enabled or both SDSUPPORT and LPC_SD_ONBOARD then the display issue doesn't happen.

As best I can tell accessing both SD cards is working.

I am a bit concerned about the availability of the SD card to Marlin. Most of the time you need to mount the SD card for Marlin to see the files but sometimes they are available immediately after a reset/power-up.

If you want to use the LCD's SD card then we'll need to investigate further. In that case please open a new issue for it.

As short term way to use the LCD's SD card without the garbage issue is to move pins 3 and 5 from the LCD adapter to the ethernet connector. This way the LCD and the SD card are not sharing any signals. You'll need to edit the pins_RAMPS_RE_ARM.h file and change LCD_PINS_D4 (pin 5 on the cable) and LCD_PINS_ENABLE (pin 3 on the cable) .

[Bob-the-Kuhn]

FYI

[Anycubic]

Hello @Bob-the-Kuhn , thank you for you answer. Unfortunately I have the issue even with SDSUPPORT and LPC_SD_ONBOARD enabled. Actually I have the problem even with SDSUPPORT disabled! So maybe is it just I made some weird pins configuration which were working with older releases and now not working? I'm attaching config files that I'm using, maybe I'm doing something wrong in re-arm pins.
Thank you
LPC_SD_LCD.zip

[Bob-the-Kuhn]

I found the display problem. The TMC software SPI and the LCD are using the same signals.

You'll need to change the TMC software SPI pins. They're actually defined in two places (Configuration_adv.h and pins_RAMPS_RE_ARM.h). Best to comment out one and update the other.

Also, I suggest commenting out USB_SD_DISABLED. That'll allow the onboard SD card to be mapped as a drive on the PC which should stop you from having to move the SD card from the Re-ARM to the PC and back again when making configuration changes.

[Anycubic]

I have a Ramps 1.6+ and Re-Arm HW SPI with TMC2130 is not working (SPI pins are "hard wired" on that Ramps board), I'm using a workaround which is using same PINS for HW SPI re-routed to SW SPI (from here https://www.youtube.com/watch?v=TtYmx60rZh0) and it is actually working. So maybe I could change the relevant LCD SPI pins? Thank you

[Anycubic]

And BTW, using a I2C display (like Tiny OLED) could help fixing SPI issues with my configuration? Thanks @Bob-the-Kuhn

[Bob-the-Kuhn]

Early in the video it was stated that the LCD and the TMC (and the LCD's SD card) all share the same SCK & MOSI.

The principle is the same for the Smart LCD - need to NOT share any pins with the TMC SPI. I think that just means moving the EXP1 cables pins 3 & 5 to the ethernet connector.

In cases like this I use a breakout cable like the Adafruit 1199

[Anycubic]

Ok, in the meanwhile I will just disable the LCD and will use ESP3D to manage the printer. I'm wondering whether this SPI conflicts are causing shift layers as well

[Bob-the-Kuhn]

I doubt that the SPI conflict has any effect.

Layer shift is usually caused by skipped steps. The culprits tend to be:

• Too small of a step pulse width.
• Microsteps set too high.
• Speed, acceleration and/or jerk set too high.

[Anycubic]

Well, I can tell you today I have been playing all day long with my printer (I changed many parts in these days, Re-Arm, TMC2130, 24V upgrade, et etc). After I disabled the LCD some big "random" shifts disappeared (maybe CS SPI pins were being affected?) and adding cooling to the motors solved other "little" random shifts, of course I was testing always with same object. Maybe next step will be testing a I2C display

[Anycubic]

@Bob-the-Kuhn I'm trying to apply the changes that you suggested but can't see REPRAP_DISCOUNT_SMART_CONTROLLER section in pins_RAMPS_RE_ARM.h. Where do I need to make the changes? Thanks

EDIT: just figured it out, working good now!

[Bob-the-Kuhn]

Well, shoot. Looks like I didn't save a comment.

Have you tried the TMC drivers? I expect that they are not working.

I suspect that you can't change the TMC software SPI pins because they're hardwired. That means you'll need to change the LCD pins.

Change the second occurrences of #define LCD_PINS_ENABLE and #define LCD_PINS_D4 to whatever is convenient.

[Anycubic]

Exactly what I did, everything is working fine now ;-) When I'll have some spare time I'll try to make the LCD SD work, I don't have any PC close to my printer so for me it was very useful. Uploading with ESP3D at 250000 on serial is very slow....maybe Re-Arm is reliable with higher serial speed, need do test that as well.
Thanks a lot!

[Bob-the-Kuhn]

You are using an ESP32 WIFI module to interface to the controller? Very interesting.

Do you still have a cable between the Re-ARM and your PC?

If there is no cable and you are uploading new firmware via the WIFI link then I want to know the following EXACTLY so I can also use it:

• How the hardware is setup/connected
• Marlin setup
• What you are using on the PC side for the host interface
• What you are using on the PC side to do the upload

[Anycubic]

Actually I just put the firmware.bin on the board microSD (it takes me 30 seconds to get to the printer from my Mac). I guess I could send the bin file like I send the gcode, but I don't know if ESP3D makes any "optimization" on the files it sends (I understood it DOES makes optimization on the gcode files to reduce uploading time).

Setting it was pretty straightforward:

• installed the latest ESP3D code on a NodeMCU and configured it
• didn't touch anything on the Marlin side
• plugged the NodeMCU to Re-Arm UART port
• dang! you just use a browser from your phone/Mac/PC whatever pointing to the NodeMCU (I assigned a static IP but you will see the IP on the printer LCD screen) and you manage your printer with it

[Bob-the-Kuhn]

The firmware update has always been the hard part. Until that can be done wirelessly I'll stick with my USB cable.

Thanks for the info.

[Anycubic]

Just to add that with 2.0.5.3 LCD SD is working fine!

[thinkyhead]

Good to hear. Version 2.0.6 is due pretty soon, so let us know if bugfix-2.0.x is exhibiting any issues that need fixing.

[Anycubic]

Actually 2.0.5.3 is working PERFECT on everything, RE-ARM + TMC2130 + REPRAP_DISCOUNT_SMART_CONTROLLER + servo extender for fans. The only issue I have is FAN pulsing on heated bed switching on/off (latest bugfix I tested didn't have this issue) but nevertheless I think I will stick with 2.0.5.3 forever!!!

[thinkyhead]

Great to hear! I know with some board / peripheral combinations 2.0.5.3 has quirks. But, when 2.0.6 comes out, you can always check the release notes to see if there's anything that might affect your babies.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.