MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.28k stars 19.23k forks source link

[Bugfix 2.0.x] rearm and RepRapDiscount Smart Controller #11927

Closed Bergerac56 closed 6 years ago

Bergerac56 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

thinkyhead commented 5 years ago

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

AnHardt commented 5 years ago

That's the best i can find.

thinkyhead commented 5 years ago

That's the best i can find.

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

…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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

p3p commented 5 years ago

https://github.com/MarlinFirmware/Marlin/pull/7390#issuecomment-320371735 is what I built to test with (thanks @tcm0116 I had no idea where I had posted them)

tcm0116 commented 5 years ago

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

Bergerac56 commented 5 years ago

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

rearm-exp1

thinkyhead commented 5 years ago

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 commented 5 years ago

lcd2004 v2

EDIT: Replaced the original image with updated one below.

Bergerac56 commented 5 years ago

@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 commented 5 years ago

@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. lcd2004 v2

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

mini-re-arm pinout

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)

mini-connector

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

mini-connector rearm-3

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

mini-connector glued-4

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

mini-connector soldered

And that's it :)

mini-final

Anycubic commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@Anycubic , will anycubic use ReArm in future product ?

Anycubic commented 5 years ago

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

Anycubic commented 5 years ago

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 commented 5 years ago

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

Bob-the-Kuhn commented 5 years ago

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 commented 5 years ago

FYI Re-ARM bottom Rev 3 Re-ARM left Rev 2 Re-ARM right Rev 2

Anycubic commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Bob-the-Kuhn commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I doubt that the SPI conflict has any effect.

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

Anycubic commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

Anycubic commented 5 years ago

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:

Bob-the-Kuhn commented 5 years ago

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 commented 4 years ago

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

thinkyhead commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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[bot] commented 4 years ago

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.