I think you need to start with https://github.com/Allted/Marlin/tree/V1CNC_Ramps_Dual instead of the “MPCNC_…” versions. Those are older and probably need to be cleaned out since it is easy to make that mistake.
Agreed. I can see if I have permissions to do so. I should also clean up the choose version readme.
Sorry. Heath.
Thanks! I’ve got the 425D version downloaded now. For the laser usage, do I still need to comment out those lines in Marlin.cpp?
I think so.
I got 425D flashed and the movement is smooth again, but now my LCD display is all weirded out. I verified the correct LCD was defined (REPREP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER).
The TFT32 I also have attached works just fine. I just can’t use it to resume from a gcode pause.
Found the fix for that on Reddit. Leaving it here in case anyone else has the issue.
Marlin 2.0? I recently updated from 1.1.9 and this happened on my similar setup. Setting a delay in configuration.h is a workaround. You can instead edit src/lcd/dogm/ultralcd_DOGM.h and change “#define U8G_CLASS U8GLIB_ST7920_128X64_RRD” to “#define U8G_CLASS U8GLIB_ST7920_128X64_1X” for a permanent fix without delays. The problem is that ultralcd_impl_DOGM.h is not used in the 2.0 source tree
https://www.reddit.com/r/Reprap/comments/e80co2/how_to_fix_garbled_lcd_screen_data/)
Everything looks good so far.
1 Like
I see what’s going on with the branches. At some point between 414 and now, 2.0.0 was released, and Ryan had been working directly off of bugfix-2.0.x before that. When he updated to 2.0.0, the code history got a lot cleaner, and I think we’ll get more stability. When he did that, he renamed the branches to start with V1.
At the same time, he had been supporting RAMPS this whole time, but hadn’t sold a RAMPS board in more than a year. So I think he dropped the Ramps configurations.
I recently took a rambo configuration and made a Ramps version. But I don’t have a Ramps stack in action either, so it has a more “alpha” tag to it. Be warned.
I am still planning on getting these configurations to be a lot better, incorporating the work from anttix, and we should be able to provide some clean configurations for lots of boards. That’s a while away though.
My board is basically RAMPS (MKS Gen L) and I use Rambo with a one-line change for the motherboard, and everything works. (And then on top of that I’ve made a lot of special modifications myself.)
So I think Rambo + motherboard change is a good working baseline for RAMPS.
1 Like
MKS Gen L here too. I downloaded the “Ramps Dual” and changed the line for the board, and a couple other minor tweaks and it seems to work just fine.
I have run into an issue with 425D now that I’ve actually tried to run a real job today. I have the IoT control pins connected to the extruder heater pins on the board and turn the relay (and the spindle or laser module) on and off with gcode (M104). With no extruder or heatbed defined, I can’t turn on my IoT Relay with gcode.
I changed “#define EXTRUDERS 0” to “#define EXTRUDERS 1” but when I try to compile, I get a ton of “Error while detecting libraries included by…” errors and the compile fails. Change the number of extruders back to 0 and it compiles just fine.
M104? Do you mean M106? M104 is for one of the hot end temperature.
What pin do you have it connected to? Have you tried just using M42?
I have the IoT Relay input sensor connected to D10. So yep, M104.
M104 S200 ;Turn IoT Relay On
M104 S0 ;Turn IoT Relay Off
Or if I want to turn it on from the LCD, I just go to Temperature -> Preheat PLA (or ABS, whichever one I happen to land on as it doesn’t matter). I did this to reserve the fan (using M106 Sxxx) for laser control.
But M104 does nothing. In the temperature menu, the only option I have is for the fan speed. And I didn’t even notice it before, but the temperature section on the home screen on the LCD is empty.
Oh. I didn’t think that would work. I guess you disabled all kinds of temperature checks?
Can you try M42 P10 S255?
Did it tell you which library was missing when you tried extruders=1? I am guessing there was a library warning and an error message about not having enough drivers for Y2.
I don’t keep a computer hooked up to it so I’ll try that next time I take my laptop out there. But I really don’t want to have to edit all my existing gcode files as a workaround. Plus I still wouldn’t have the “Preheat” menu options to turn the IoT on manually.
It didn’t tell me which library was missing, just “Error while detecting libraries included by…” and then the file that supposedly referenced the library, but it was just about every single file. And yeah, then several errors about not enough pins for Y2.
I’ve been combing through the files, comparing the 425D version with the 414D and 302 versions where this worked for me and I just can’t figure out what I need to change in 425D. I may just go back to 302.
Do you have a ramps or a rambo? If you want EXTRUDERS=1, then you’ll need to change the pins in the pins file. If you look at your pins_RAMPS.h in your 302 version, you can see the juggling it did, and it added an E2.
I think the library thing is a red herring.
Ramps (well, MKS GEN L, but the same thing). I thought I compared that file and didn’t see much of a difference. But maybe I didn’t. I’ll take another look.
You should see the pins on E0 set to 70 and then a new E2 set to the pins from E0. You can make those changes yourself, if you find the right pins file.
425D pins_RAMPS.h:
E0_STEP_PIN 26
E0_DIR_PIN 28
E0_ENABLE_PIN 24
E0_CS_PIN 42
E1_STEP_PIN 36
E1_DIR_PIN 34
E1_ENABLE_PIN 30
E1_CS_PIN 44
302 pins_RAMPS.h:
E0_STEP_PIN 70
E0_DIR_PIN 70
E0_ENABLE_PIN 70
E0_CS_PIN 70
E1_STEP_PIN 26
E1_DIR_PIN 28
E1_ENABLE_PIN 24
E1_CS_PIN 42
E2_STEP_PIN 36
E2_DIR_PIN 34
E2_ENABLE_PIN 30
E2_CS_PIN 44
So I notice E1 is different between them. So should I leave E1 alone in 425D, move E0 to 70 and E2 to the E0 pins? Or make E0, E1, and E2 all have the same assignments from the 302 version?
And, btw, thanks SO MUCH for your help!
The 302 pins are correct. My mistake.
So, by doing it this way, did you disable the runaway and other heater safety features? It seems like Marlin would be angry that it wasn’t heating up… Oh wait.
Because the dummy thermistor is set to 170C, so it thinks that is the temp. So long as 170C is close enough to the set point, it won’t know the difference.