I’ve been using build “302” of the V1 Engineering preconfigured Marlin from GitHub since building my MPCNC. I just updated to build “414D” and now my cut moves are not very smooth. This caused a problem with a laser job today where the tool seemed to pause a moment at each change of direction causing an uneven burning and little blobs everywhere (pic attached). When using the spindle to cut out a shape that had many very small movements, it still cut fine but it took 4 times as long. This was using the same gcode file I had used with the old version.
My guess is this is because of one of the newer features of Marlin, but I really have no idea. Junction Deviation maybe?
Has anyone else encountered this? I’m sure there’s a thread about it I just can’t find. Is there something I should change in Estlcam? Or disable/enable something in firmware?
Why did you only upgrade to 414D? I think there were some junction deviation/arc things getting worked on then. I forget where it ended up, but I think the more recent 425D versions have that ironed out.
Interested to know if you get this sorted out. GRBL has a laser mode which removes the carriage pause while a new Sxxx spindle speed (laser power) is implemented and it also employs dymanic laser power scaling with M4 instead of M3 to match the laser power to the carriage speed to remove the burnt corners. I know work was being done on Marlin to address these shortcomings but I’m not sure how it all turned out.
You might also want to take a look at any Z commands in your gcode that will pause the carriage with the laser on while the Z command is processed. Best to remove all Z commands for laser work.
So, if I follow the link from the documents to the GitHub, choose the version for my board and configuration (MPCNC_Ramps_T8_16T_LCD_32step_DualEndstop), use the Code → Download Zip menu to download the zip file, extract that, open the Configuration.h file in Notepad++, and search for “version”, this is line #74:
#define STRING_CONFIG_H_AUTHOR "(V1 Engineering, Ryan, 414D)" // Who made the changes.
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/)
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.
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.
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.
