3D Printer: Creality Ender-2
Configured Board: BOARD_MELZI_CREALITY
Configured Graphical LCD: MINIPANEL
Running on latest Marlin-bugfix-1.1.x firmware
Link to configuration zip: https://github.com/3DFreezeMe/Marlin-issues-files/blob/master/Marlin-bugfix-1.1.x.zip
OK:
NOK:
(possible) related Marlin Github issues:
7213
7211
7155
1. Configuration.h
Connecting...
start
Printer is now online.
echo:Marlin bugfix-1.1.x
echo: Last Updated: 2017-05-04 12:00 | Author: (none, default config)
Compiled: Aug 9 2017
echo: Free Memory: 11819 PlannerBufferBytes: 1232
echo:EEPROM version mismatch (EEPROM=V39 Marlin=V40)
echo:Hardcoded Default Settings Loaded
echo: G21 ; Units in mm
echo: M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z4000.00 E93.00
echo:Maximum feedrates (units/s):
echo: M203 X500.00 Y300.00 Z5.00 E25.00
echo:Maximum Acceleration (units/s2):
echo: M201 X500 Y500 Z100 E5000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P500.00 R500.00 T1000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Material heatup parameters:
echo: M145 S0 H205 B40 F0
M145 S1 H235 B65 F0
echo:PID settings:
echo: M301 P21.73 I1.54 D76.55
echo:SD init fail
>>> M20
SENDING:M20
Begin file list
End file list
2. Configuration.h
//#define SHOW_CUSTOM_BOOTSCREEN
Pronterface output when connecting:
Connecting...
start
Printer is now online.
echo:Marlin bugfix-1.1.x
echo: Last Updated: 2017-05-04 12:00 | Author: (none, default config)
Compiled: Aug 9 2017
echo: Free Memory: 11819 PlannerBufferBytes: 1232
echo:EEPROM version mismatch (EEPROM=V39 Marlin=V40)
echo:Hardcoded Default Settings Loaded
echo: G21 ; Units in mm
echo: M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z4000.00 E93.00
echo:Maximum feedrates (units/s):
echo: M203 X500.00 Y300.00 Z5.00 E25.00
echo:Maximum Acceleration (units/s2):
echo: M201 X500 Y500 Z100 E5000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P500.00 R500.00 T1000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Material heatup parameters:
echo: M145 S0 H205 B40 F0
M145 S1 H235 B65 F0
echo:PID settings:
echo: M301 P21.73 I1.54 D76.55
echo:SD card ok
>>> M20
SENDING:M20
Begin file list
CR-10_~1.GCO 2315020
End file list
7211,7155
1. Added the following to Configuration.h
#define SHOW_CUSTOM_BOOTSCREEN // 3DFreezeMe
#if ENABLED (SHOW_CUSTOM_BOOTSCREEN) // 3DFreezeMe
#define CUSTOM_BOOTSCREEN_TIMEOUT 1000 // 3DFreezeMe
#endif // 3DFreezeMe
--> did not help (tried several values for CUSTOM_BOOTSCREEN_TIMEOUT without success)
2. Added the following to Conditionals_LCD.h (I commented '//' the changes made in Configuration.h for CUSTOM_BOOTSCREEN_TIMEOUT as they are double now)
// Boot screens
#if DISABLED(ULTRA_LCD)
#undef SHOW_BOOTSCREEN
#elif !defined(BOOTSCREEN_TIMEOUT)
#define BOOTSCREEN_TIMEOUT 1000 //2500 // 3DFreezeMe
#endif
#elif ENABLED(MAKRPANEL) || ENABLED(MINIPANEL)
#define DOGLCD
#define ULTIPANEL
#define NEWPANEL
#define DEFAULT_LCD_CONTRAST 17
#define BOOTSCREEN_TIMEOUT 1000 // 3DFreezeMe
#define CUSTOM_BOOTSCREEN_TIMEOUT 1000 // 3DFreezeMe
--> did not help (tried several values for TIMEOUT without success)
7213
3. Did not try to add this, as I already have #defined the values in Conditionals_LCD.h
Regarding odd display behavior, not sure if it's relevant but my LCD12864 required additional delays to work 100% correctly:
#define ST7920_DELAY_1 DELAY_5_NOP
#define ST7920_DELAY_2 DELAY_5_NOP
#define ST7920_DELAY_3 DELAY_5_NOP
I have seen this in some open/closed issues. But why would only the SD card menu be affected? All other menu's I have work ok, without the 'banding' issue.
Of course I would try adding delays for testing purposes, could you give me the values you have had success with?
The SD card is btw not on the LCD panel, it is on the Creality Melzi board itself and possibly not related to this issue?
Not sure if this applies here, but since i'm using a flashAir SD-Card (about 1 week) i get a "SD init fail" after a reset too message, too. But, except for the message, everything is working fine.
Currently the linked file is broken, I am working on that.
/edit: all links have been fixed
Same problem here. First I tried th3d firmware which comes with 1.1.9. No SD card at all. Then moved on to pure Marlin and started debugging:
WORKAROUND:
That's the only way I've made it work, and all those 3 steps are required, and in that same order. The bootscreen doesn't seem to have anything to do with this bug.
Everything else works OK with the latest branch. Including the SD menu that was broken for some time. Now it looks OK, but you need to do the workaround to get the SD card to load.
Weirdest part: hitting "init sd card" while not removing it does not seem to help. You need to unplug and plug the card again to get it to load. Is there any special code that runs on this case? I wasn't able to find any, but I'm not familiar with the codebase at all. Maybe some pin left unconfigured? I tried setting MISO, MOSI and SCK pins manually right before the chip select during the SD card SPI initialization, but it didn't help. I even compared the init code with the (now released) Creality Open Source code, but I couldn't find the difference that makes it work.
Thanks.
Try adding this to the end of the setup() function in Marlin_main.cpp:
#if ENABLED(SDSUPPORT)
if (!card.cardOK) card.initsd();
#endif
This works! Thank you!
I should clarify. I'm using branch bugfix-2.0.x because I thought that moving to a newer branch would fix the problem. I added the lines at the end of Main.cpp file in setup() and now it works when I boot. So this probably also works on 1.1.x
What is the difference between that and doing the init manually in the menu selection? I don't understand why doing that at the setup works. I also don't understand why the sotck Ender-2 source code doesn't do that at the end of the setup, and it still works.
Side note on a possible bug (different than this one, but similar):
The stock Ender-2 firmware did something weird: the SD card is not properly initialized when I first start the printer right after I plug it in. I need to shutdown the printer, remove the card, insert it, and then it will initialize correctly every single time (even after a shutdown), until I remove PSU power.
Marlin is doing exactly the same after the fix.
Let me be very clear: the bug 7467 is effectively fixed after applying the changes you mentioned. My 3D printer is back to the same behaviour it used to have before upgrading, and that's great. The reason I clarify this is because maybe there is something that can be done on the software side to overcome this OTHER bug that has been around in my machine and also I'd like to know if this happens to anyone else too so I can file a new bug.
It's a matter of timing. Your SD card reader (or SD card) is slow to initialize and the usual initsd method called early in startup is seeing it as a failure. The extra initsd ensures that the card has had enough time to initialize and get the SD card ready. The Ender-2 is probably taking more time after boot-up (or at least differs in timing from the current Marlin) before it tries to init the SD card reader.
Perfect. I kept trying to find a pattern to the other bug and it turns out
it's just random. This morning the sd was correctly initialized after a
cold boot, so we can safely ignore it. The bug in this report is also fixed
after the changes you mentioned. I don't know if it can be done any other
way, or increasing the wait time somewhere else, but at least now it works.
Thank you very much
(I'm going to try increasing the SD_INIT_TIMEOUT later to see if that has any effect)
UPDATE: increasing the timeout did not help. So I'll stick with adding the lines you mentioned to the the setup() function. At least it works that way. It doesn't work once in a while, but restarting does the trick. Thank!
Hi, on marlin 1.1.8, my sd card worked flawlessly (anet a8, yes I know). With 1.1.x bugbix it never started, I always had to init SD first (by the way, there is a bug here also : I initialize and nothing changes, it's when I move up/down that LCD refreshes and displays "print from sd" instead of "no sd card").
With that fix, my sdcard works at printer boot/reboot, thank you @thinkyhead (could it go to master ? would that increase firmware space a lot ?)
I initialize and nothing changes
Using the LCD "Refresh" menu item? I can push a patch for that.
@thinkyhead I think this is referring to the menu display. I have seen the same thing. When you click on "InitSD" (or whatever the wording is). The menu often does not get redrawn to show "print from SD" instead it continues to show "No SD card" when you move the menu selector the display updates. I also sometimes see the "InitSD" message half replaced by "Change SD card" so bottom half is the new text but top is the old. I suspect this is some sort of race condition.
It's not a race condition. Just that the flag is being updated while the menu handler is running within the first segment of the graphical display. The patch (18fedafbc5f29b01d0421e5b059999ad46b0fd73) should take care of that.
@thinkyhead i think we can close this one since @3DFreezeMe has not reported back since 27 aug 2017
@thinkyhead 2nd reminder to close this. :)
_original comment edited out_
UPDATE 2: I fixed other bug that prevented the ender from working, and gave this bug a try with the latest code. It's exactly the same behavior.
Removing the SD card and clicking on Init SD Card doesn't work all the time. I often have to remove the card 2 or 3 times until the initialization works.
Is there any reason this was closed? (other than: it was old and the OP was not responding?)
Many Ender-2 users end up upgrading to better boards, so it stops being an issue for them. This issue is still valid for those of us that still use the original board.
"SD init fail" is a general symptom that pops up in various issues, and could indicate any number of causes. We do like to close issues that have been gathering dust for years and start afresh.
Also, since we don't have every machine and board and are very busy, we hope and pray that causes and solutions will be vigorously investigated by the users who have the equipment in hand — with community help, if necessary.
Clearly, no one around here has had the time, inclination, and data to solve the issue for almost two years through this post, so I would advise exploring some of the other avenues below. It could be another 2 years here…
got it. no problem. I do have the will and tools to debug this, but it's very unlikely I'll have the time in the near future. I'll see if I can hook a logic analyzer one of these days, but I understand your reasoning and I agree it's better to leave it closed. It could take quite a lot until I get the time to debug this (assuming I don't upgrade the board before).
PS: Thanks for the great firmware! This is a rather small bug. Everything else rocks.
We've been doing a lot of SD changes in support of 32-bit boards, so things like this should shake out eventually. I'll pay close attention to what happens next time I boot up a Melzi with a splash screen and an SD card inserted.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.