M106- I can’t tell for sure, but I think the issue is we are not setting a fan_speed acceleration rate. I am not understanding it completely but in planner.h Block_t (what I think the fan speed is using). Since we do not have a acceleration value maybe it is just using whatever is already in the planner?
Planner.h lines 77-160
As for M3-5, there is a line that says synchronize. If you follow that it says “Block until all buffered steps are executed / cleaned” (planner.h line 731). So maybe that line comes out and it would work for a laser?
Or maybe this I am over thinking this. Marlin describes both M3 and M106 as “Wait for moves to complete, then set…” So maybe it is actually clearing the acceleration buffer and the next X or Y move seems as if it is starting from 0? That would force an acceleration. So to test this, a slower etch (with a lower power to give the same approx burn color) should show less acceleration darkening. Or set the Jerk or junction deviations really high to try and eliminate the accelerations…Dang, never easy. If this is the case we could possibly store the current acceleration/travel speed value, then send the m3 or M106, then reinstate the previous acceleration/travel speed value?
hmm. you are right.
M3 (doesn’t mattar is it M3 O or M3 S)/M5 call planner.synchronize();
M106 doesn’t.
so you may see a little stall at these commads.
difference between M3 O255/M3 O0 and M3 S255/M5 is that last one uses:
// Wait for spindle to come up to speed
inline void delay_for_power_up() { gcode.dwell(SPINDLE_LASER_POWERUP_DELAY); }
// Wait for spindle to stop turning
inline void delay_for_power_down() { gcode.dwell(SPINDLE_LASER_POWERDOWN_DELAY); }
and even if you set macro values to 0
and
/**
* Dwell waits immediately. It does not synchronize. Use M400 instead of G4
*/
void GcodeSuite::dwell(millis_t time) {
time += millis();
while (PENDING(millis(), time)) idle();
}
to avoid call to idle() you have to set delay to -1
so probaly it’s easier to just use M3 O.
The stops might also be due to the gcode motion. I wonder if you took out the intermediate M106 commands if it would still pause. Maybe it’s not doing the motion planning itself right and it thinks those are corners or something.
Oh, I didn’t realize it was in the same zip. Thanks.
[scode]
G1 X0 Y0.5
G1 Y0.6
M106 S231
G1 X0.1
M106 S144
G1 X0.2
M106 S52
G1 X0.3
M106 S1
G1 X0.9
M106 S3
G1 X1
M106 S1
G1 X74.6
M106 S2
G1 X74.7
M106 S75
G1 X74.8
M106 S167
G1 X74.9
M107
G1 X74.9 Y0.7 F3000
[/scode]
This is strange looking. It does a bunch of moves incrementing the power a little (X0.1 X0.2 X0.3 X0.9) and then it jumps from X1 to X74.6 and then ramps down (X74.6 X74.7 X74.8 X74.9). I think this segment must be for the border, because it’s drawing 75mm wide. If I jump into the middle of the file, I see a similar pattern on the individual squares:
This is two blocks. But there are a lot of different points. It looks like image2gcode is trying to compensate for the acceleration of Marlin. That would work if it was using close to the same acceleration and jerk values. Marlin would also have to see these moves as continuous, and not try to stop on them.
Does anyone know if Marlin is actually doing a good job at determining when straight lines are a corner? I thought this was working, but I remember some gcode that made me think it wasn’t. I wonder if I should cook up some manual moves to see if it is working, both something like this:
In the second case, the buffer for the planner might be getting drained, so it doesn’t know it’s going to be going straight forever. In the first, I would be surprised if it stopped. I hope it’s easy enough to see (although temporarily making the acceleration really small should make it worse).
The motion_test.gcode went fine, but the buffer_test.gcode was very jerky. I think it’s starving the buffer in my test, although this is admittedly harder than the shades of gray one.
As I’m thinking about this though, that might not be image2gcode adjusting the acceleration as much as jpeg compression having artifacts on sharp transitions…
I will add some M106 codes to the motion_test and see if it’s still smooth I think that will give us some answers about the lasers.
This has laser_motion_test.gcode, which includes the fan commands every 10mm. It doesn’t pause at all. The fan commands aren’t causing accelerations (yay!?)
So I think this is about as close as we can hope for. I suspect:
The start and stop of each row will always have the acceleration artifacts. At least until we have a laser mode in Marlin that will try to adjust the power when not at full speed.
The ones in the middle are due to a starved buffer, so the planner can’t see that it’s still on a long straight line, so it slows down enough to never exceed the acceleration limits.
The reason it’s starved is there are lots of 0.1mm moves in between the blocks, due to either the original image’s jpeg compression.
Does image2gcode support svgs? I wonder what the gcode and laser output would look like for an image like the Japanese flag?
If it still has the 0.1mm moves, then maybe it’s a question for the author of image2gcode.
There are configuration values to increase the buffer size. I don’t think the 328p is that low of flash that a bigger buffer would hurt. Maybe Guffy would have some idea on that?
Um. I took a video of the buffer_test.gcode, and I think I had too much coffee… It’s pretty hard to see how jerky the machine was when my arm was floating around all over the place.
As a side note. I fired up my laser again this morning before work. Bad idea I think. It was 15 Degrees Fahrenheit. I think I broke my laser module. It wouldn’t turn on for my second test. I worry the sitting cold then heat from running then cold again (with a cooling fan) may have cracked something on my Cheap 15 watt.
In any case I ran the Shades of Grey Gcode through Marlin 2.0 and 1.1.5. They both produced the same stop & Start movements. Even when I replaced M107 with M106 S0. So I was wrong about 1.1.5 not doing that. But something is still strange. Because I know for a fact that the Horse image I burned looked great. And it was constantly changing the laser power with M106 commands to get the grey scaling to change. So If the problem really is firmware then I somehow didn’t notice with that horse image.
I am suspect of the Shades of Grey Gcode. I agree with Jeff that it should have fewer M106 commands. it should be more uniform. I believe the varying shades are the product of the raster image sampling each pixel slightly differently but I would like to see a test file with fewer variables.
I don’t know why I didn’t think of this before. In my laser calibration gcode file the speed stays the same for each line it draws. But it is constantly increasing the laser power with M106 commands. And yet the results are a beautiful darker progression. No accelerations until the end of the line. If you look close you can see the darker edge where it is slowing to a stop before it ends the line.
Yeah, that’s what I’m seeing is the behavior with 2.0 and the Marlin.cpp edits. I don’t have the laser working yet, but that’s the motion I’m seeing with the firmware configured for it.
Jpeg compression has a hard time with hard edges (it low pass filters images, and discards high frequency information). The svg doesn’t have any compression, and it’s sharp no matter how far away you are. Things like cartoons, logos, text, and diagrams would keep that sharp edge in an svg format.
You could potentially trace the shades of gray image in inkscape, and it would smooth out those artifacts, and return the rectangles to sharp edges. You’d have to be careful with the settings to keep the shades the same though. I could work on something like that later.
Before we figured out the problem and a workaround, in all my attempts to print Garfield, I noticed that the jpeg artifacting was having an effect. It was making the laser run in places where it shouldn’t but at a power so low it had no effect anyway. During my straw grasping, I did some editing to the image to remove as much of the artifacting in the white space around Garfield as I could and generated new gcode with both Image To Gcode and Image2Gcode (one of those should really change their name). It helped with the burn time, eliminating unnecessary movements, but that was obviously the only thing it helped.
Neither “To” nor “2” will handle SVG files. The Jtech laser gcode plugin for Inkscape won’t handle the fill, just the paths.
Is there a free-ish program that will handle SVGs but also handle both the paths and fill?
EDIT: “50-shades-grey.zip” file added containing a SVG file.
Awesome, M106 is a buffer issue, +the delay… There are some things we can try but, not being a fan acceleration makes my day, and means I am not a complete dodo for not finding it in Marlin. Silver lining I understand Marlin a little better.
fan commands itself do nothing with the motion queue.
right
i dunno. have no experience in programming motions. i guess it’s similar case as 3d printing of linearized arc with big radius. it’s question to marlin authors.
i think that’s сommon property of all raster (but not only) images. maybe author of that application just issued a block of command per pixel and doesn’t try to optimize a line. but a lot of gradients is a nature of photo pictures, so bad and worst cases will be pretty frequent.
buffer is in RAM. it just 8KB. Block_t is relative big so by default the queue has just 16 blocks. i don’t think that expanding it to more then 32 is good idea.
I still vote for overscan instead of per line power ramping (just think it would be easier to implement). The ImageToGcode has a resolution setting, maybe there is a sweet spot, the default is 0.1, our lasers vary from 0.1-0.4 spot size typically, so maybe just decreasing that to 0.3 or 0.4 might really help and not have to resolution suffer.
I have an idea for victor, and his ImageToGcode. If he isn’t following along I can message him. As it is now in ImageToGcode you can etch the picture as is, which for this Garfield is over scanned kinda because it is in a white box. If you adjust this threshold you get an optimized etch. If we had one more control, perhaps “color threshold” and those of use that chose to “overscan” could by including a dummy background color. Almost like a fake greenscreen?
