I’m testing my new mpcnc with a generic chinese 5.5W (at least sold as 5.5W).
Did you buy everything from here? => NO
a)If you didn’t or changed some things please don’t leave out any details. => No changes. Steppers are in serial connection.
b)What firmware? => Marlin 1.1.0RC7 downloaded from here.
Are you using end stops? => NO
a)If so please disconnect them.
Are you using all my recommended parts? => Yes
a) If not please list what parts you used.
Include a picture so obvious errors might be spotted. => See attachs
My laser is connected to PWM D9, it responds ok to intensity changes (M106 Sxxx).
A quick test with inkscape j tech photonics (https://jtechphotonics.com/?page_id=2012) looks great.
There is some kind of pattern, every 14/15 lines, is like the laser engrave out of the place for some time.
Should it be a mechanical issue? Stepper driver issue (DRV8825 at 0.7v, my motors are 1.5A rated)? Laser driver issue?
The x movements seems a bit bumpy/jerky…
Martin this has come up a few times recently. I’m not sure what it is. My laser has done this as well. I have gotten clean pics though. I will have to put the laser on this evening or tomorrow and see if I can help trouble shoot this.
Since you are using a different laser and driver, we can rule those components out. I hope.
That leaves.
Lcd SD vs over USB (could be a communication speed thing)
speed (could be an arduino buffer thing)
acceleration (multiple speed changes, also maybe increase the jerk for the laser to ignore small accel changes)
software (bad “slice”)
On that link you put up this is what I am thinking the issue is.
A note on commands per second: My Printrboard can handle about 280 commands per second over USB and about 380 when printing from the SDcard. This is somewhat abstracted to this program only because commands can vary considerably in length.
When we mill or print there is a relativity long period between commands. With the laser it is very short it can try to burn 1 dot then move. where with any other functions the smallest movement is probably 100x’s that size.
I think this could be tested with a solid black square. I bet this works, same setup same accel, same software. It’s the details and tiny tiny commands. The next issue is how to fix it other than just slowing down. Optimism the code, marlin or gcode?
Leo69 explained in another post why step rate wouldn’t effect it, I can’t find it now.
It actually shouldn’t change the quality a noticeable amount, our step size is so ridiculously low we can go to about 1/8th stepping before you would notice anything I think.
Not wanting to say bad things about free software, I do think this issue may be Marlin/LCD related. A quick look at the Marlin code shows the fan control (I.E. laser control) is run from the idle loop, not the stepper interrupt - so it’s already slightly out of sync with movement. However, the LCD update routines take ~40ms for the text LCD and ~120ms for the graphics LCD. The LCD is also run from the idle loop. Patterns showing up every 14/15 lines are most probably because the LCD refresh/update is delaying getting to the code to turn the laser on/off while the steppers are happily moving via the interrupt. The Marlin guys are working on making the LCD routines better (I saw pretty bad circles due to the LCD taking up too much time and they also said the delta machines need more CPU and are affected by the LCD refresh). Just my 2c thoughts though, and I use GRBL for this sort of thing and only change firmware if I’m going to 3D print something big (otherwise I’d use my CTC 3D printer).
Edit: You could possibly test this, if you disable the Marlin 30 second menu timeout, by entering the menu system and leaving it there (it doesn’t update the LCD unless you touch the controls) and let the thing finish the job… Or enter the menu and run the job while going ballistic on the controls to see if the laser image is a whole lot worse.
Jasoroony is totally right about the LCD. I’ve posted in the past about how you can see the movement stutter coinciding with the display updates on the LCD. I’ve disabled the updates on my firmware to get around this but I never noticed that it caused the issue with lines running out of the image. Possible for sure though. Have you tried increasing the acceleration values? You can do this with preprocessor gcode so to don’t need to change in your config. H. This timing mismatch between the fan control and the steppers shouldn’t be noticeable in the burned image but it would be nice to see it fixed. I’ve modded my own firmware for increased pwm resolution and better timing . I’d post instructions but I know they’ll be impossible to support with new Marlin releases coming out on a regular basis.
Can you post the source image and the gcode? I’m wondering if this is related to the stronger laser that you’re using. You’re setting max pwm power at around 60 and the software is interpolating grayscale pixel values between 0 and 255 into power values between 0 and 60. You’re losing about 75% of your grayscale resolution. What laser driver are you using?
Firsts test with Marlin 1.1.0 RC7 + Bugfixes up to 20161130 with ENSURE_SMOOTH_MOVES defined…
Much better, but still some artifacts…This image is the same gcode file as the first picture in this post printed with newest marlin fw (1200 mm/min, default acceleration).
No but you can get an sd card adapter for the ramps for a few dollars. You start it from repetier or matter control then you can disconnect but then you have no control after that. I don’t know if that would change anything. Actually it might still work from the screen. One of the two ribbon cables is only for the SD card I think and the other is for the screen. You might be able to unplug the screen and just use the sd card. Of course to see any benefit you would need to change the firmware to a non LCD version.
I have to take off for a while today but I can look into this tonight if you don’t get to it.
