Amost there- Eleksmaker A3 Pro

[troth530]

Step idle delay ($1=255) may have helped! Still need to confirm with some more tests.
I might also be able to get away with $1=100, not sure. It's unclear how it' implemented from what I'm finding on the web
I need to go back and reset the stepper current because that setting may cause overheating of the motors, also I may need to turn that off at the end of the gcode stream.

So anyway the canvas effect seems significantly diminished, but I can still see the belt pitch which I'm hoping can be cleaned up a little with the new fiberglass reinforced belts which have arrived. Couldn't match what you're doing on the Shapeoko because I had already ordered them. l'll finishing up a design on limit switch holders and belt tensioners that I'll install this weekend.

I found the lighter colored MDF at Home Depot but is was coated on one side. But overall was less than $1/sq ft. Also once I shimmed up all 4 corners to get the machine level and started using flatter stock, the engravings are much darker and I may need to increase the feedrate to >3000mm/min.

Posting title is still valid, although more progress... almost there.
Thanks,
Tim

[Picengravertoo]

Thanks for the update.

We do have a 3W EmBlaser (aka LaserBlade) here with standard reinforced belts in a CoreXY configuration, but it does not have to move allot of weight like our Shapeoko does. It has two puny steppers on it too. We had major problems with it achieving any quality laser photo/image engravings when we first received it after there Kickstarter campaign ended. We had to make some mechanical modifications to it which they implemented the changes after our recommendations.

viewtopic.php?f=13&t=35

We also changed to these grbl settings which increased the EmBlaser's performance.

$0=30 (step pulse, usec)
$1=255 (step idle delay, msec)
$11=0.005 (junction deviation, mm)
$120=10000.000 (x accel, mm/sec^2)
$121=10000.000 (y accel, mm/sec^2)

I suspect some of the canvas effect is caused by the .1mm Pixel Resolution setting your using. The burn lines has to be overlapping, especially when engraving at a 45D angle which makes the burn lines even closer together than using the Horizontal & Vertical angles. The laser's burn lines should be laying down next to each other without any gaps, or overlapping. Not only does the PR set the step over, it also sets the step ahead, so those very short .1mm incremental moves may be causing a slight stutter, especially when using grbl 1.1f. But, the amount of stuttering will depend on your X&Y accel settings.

Have you tried increasing the PR setting and have you flashed the MultiMode grbl 1.0c firmware to your board like I suggested? If your still using 1.1f, I don't recommend activating the Dynamic Laser Mode with the M4. It may be contributing to the canvas effect too, but I could be just speculating. If you get darker burn lines around the edges from instantly reversing directions, use the Extended Edge option instead.

What gcode streamer are you using? Our PicSender was developed side by side with the EmBlaser to stream the very large, fast changing raster gcode files our image to gcode programs create. Not all grbl gcode streamers are created equal!

[troth530]

Hi Jeff,
I think the $1=255 was the main fix for the canvas issue and the canvasing was actually drift related to the detents on each full step. I'll run some side by side comparisons to put it to rest. Actually I'll have to go back and triple check 0.1mm pixel res, it did in fact always seem small to me. However I have minimal overlap if any at 0.1 even on a diagonal. At 0.14mm there is actually quite a bit of separation and the sweet spot may be more like 0.11 or 0.12.

Agree with you on not all streamers are equal, but I've done tests and in my case the result has the same regardless of Gcode streamer with respect to canvasing, backlash and so on. When any studdering was present, but it's actually rare and in the case or two when I saw it, it was related to the computer being bogged down, not the port and not FW overhead. It's a nano, but seems to do fine to keep up independant on FW also. This seems to use a custom Arduino nano that seems to have 2 clocks (I haven't studied the hardware extensively. One minor downside is it does not use the FTDI, it uses the CH340 for serial data which has known issues that is just a limitation of the HW, that I've always been aware of.

And of course the backlash is mechanical. I think the motors are just weak, and I suspect even less torque than the Emblaser, but I'm also currently running 1/16 microstepping which is another loss of torque I can address later. I cannot get to those accel levels with my motors actually. They're definitely sub 1000mm/sec^2 motors, but that might be improved with additional torque per step I can get with 1/8 microstepping (1/16 is overkill given that my simple math shows the pixel resolution is optics limited).

Overall it is a really cheap machine, I have realistic expectations accordingly, and there is still work to make the most of it.

Almost there is a glass is half full mentality (optimism) as I'm now developing an eye for areas for improvement, BTW.
Thanks,
Tim