Image2gcode engraving - how to improve it

[martindb]

I’m testing my new mpcnc with a generic chinese 5.5W (at least sold as 5.5W).

1. 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.

2. Are you using end stops? => NO
   a)If so please disconnect them.

3. Are you using all my recommended parts? => Yes
   a) If not please list what parts you used.

4. 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.

Then I try image2gcode mpcnc edition (downloaded from https://www.v1engineering.com/forum/topic/image2gcode-free-raster-image-laser-engraving-software-modified-for-mpcnc/page/6/#post-15455) and I have results as attached. This picture is with PWM max to 63, speed 1200 mm/min, 0.18 mm dot size, no acceleration changes from the default vicius firmware over mdf.

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…

[vicious1 (Ryan)]

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”)

[martindb]

Thanks Vicius!

All my tests are from the SD, so the usb/serial should not be the problem.

I’ll try this page http://nebarnix.com/img2gco/ to convert the image to gcode… same speed, same power of my image2gcode test to compare.

[vicious1 (Ryan)]

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?

[martindb]

If the problem is related with the steps quantity, going to 1/16 microstepping should half them… also the quality…

If it’s related with the cpu power, a 32bits board like smoothieboard may be a solution for this kind of works…

[vicious1 (Ryan)]

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.

[martindb]

Same image, “sliced” with http://nebarnix.com/img2gco/, same power, same speed… it seems better, but same issue…

[martindb]

Same image, image2gcode mpcnc edition, power 0 to 56, 800 mm/min… the lines out of place still there…

[jasoroony]

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.

[martindb]

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?

[leo69]

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.

[martindb]

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.

[leo69]

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?

[martindb]

Sure. Original source image and gcode attached.

This is the laser with driver:

US $62.1 55% OFF|5.5w high power 445NM focusing blue laser module laser...

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)

[martindb]

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).

[martindb]

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

[martindb]

Same gcode file from post 21751, new firmware… much better… but still some artifacts…

[jnsbanman (Jason)]

Is there a way to unplug just the display and keep access to the SD and then initiate an SD print from Repetier host?

[vicious1 (Ryan)]

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.

[jnsbanman (Jason)]

@vicious1 are you possibly going modify the new version of Marlin for MPCNC… which would solve this issue for everyone?