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.
Same image, “sliced” with http://nebarnix.com/img2gco/, same power, same speed… it seems better, but same issue…
Same image, image2gcode mpcnc edition, power 0 to 56, 800 mm/min… the lines out of place still there…
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.
Thanks Jasoroony, it make sense.
In the current RCBugFix branch of marlin repo, it seems that developers take care of this… no updates to LCD if the segment is too short…
https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Configuration_adv.h#L505
Time to try last marlin version?
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.
Thanks Leo. I’ve tested with 2000 mm/s^2 in the gcode but no change at all.
I’ll try rcbuxfix branch to disable lcd updates in short segments.
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?
Sure. Original source image and gcode attached.
This is the laser with driver:
As the driver ttl logic is inverted, I’ve connected a npn transistor between D8 output and driver input to have S0 no power at all, S255 full power.
foto_0_63_1200.gcode_.zip (356 KB)
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).
Same gcode as previous but with this gcodes added to change acceleration and jerk:
(Generated by 3dpBurner Image2Gcode v0.4-DECIMAL PATCH)
(@Nov./29/2016 06:39:42)
M107^M
(Header)
G0 X0 Y0
(Header end)
G90
G21
G1 F1200
M201 X5000 Y5000
M204 P2000
M205 X20 Y20
G0 Y62.862; Move to top left corner and begin box
G92 X0 Y62.862
M106 S5
G0 X100
G0 Y0
G0 X0
Is there a way to unplug just the display and keep access to the SD and then initiate an SD print from Repetier host?
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.
@vicious1 are you possibly going modify the new version of Marlin for MPCNC… which would solve this issue for everyone?
For sure!
I think I will just make a whole separate laser firmware since it needs to get flashed anyway. Re tune it for max accel and jerk.
No way will I let all your hard work sit in a forum thread…No sir!
I appreciate all that you are doing. Kills me that I can’t fire my laser up right now and help out. I am pretty much booked until next Monday. I really want to spend some time and check out all the improvements you guys have made. Also need to get some good test files So I can put together a cool little getting started with a laser post.
That would be awesome. Laser work has became my life. I have done one router job and about 600+ hours of laser work. This machine has paid for itself many times over!
If you need any help let me know. I can test etc.
I’m not sure if it was posted here or on another thread but someone mentioned that the latest RCBUGFIX version of Marlin can be configured to disable LCD updates on short moves.i confirmed this last night. Smooth as butter, no more jerk at every display update.
Btw, started working on image2gcode v2 last night. Will add rotary support with 3d preview and “skip white” options to diagonal and horizontal scanning. That should put it right there with the commercial packages. It will be a vicious1 exclusive of course:)
Excelent Leo!
I also tested the new marlin rcbugfix branch and no more jerk movements at all… but still some minor artifacts in my picture. I’ll test with other pictures.
I can’t wait to see image2gcode v2!!!
