I think this issue was briefly mentioned in here: Laser: True grayscale instead of dithering? but it’s really causing a problem for me at the moment. @MadHatter, did you ever have any revelations on getting the machine not to stop?
While doing grayscale images that continuously change the laser power travelling at a constant speed, every laser power change causes the machine to come to a brief stop. This wrecks power regulation.
There has to be a way to modify the Marlin core so the motion planner doesn’t decelerate to do a power change.
Until that’s fixed exact grayscale reproduction will be a compromise at very slow speeds to minimize the acceleration affect.
I’m wondering if a temporary workaround would be to modify the acceleration limits at the start of the file. Would the acceleration need to go up? Down? Both could work I think, for different reasons.
Luban doesn’t change power when printing grayscale. It just generates more dots for darker areas. How it does this is dependent on the algorithm you choose.
So you’re getting banding because it’s unable to smoothly transition from levels of gray. It’s the same thing that happens in a graphic program if you try to convert a file to one with less levels of gray.
Strangely they’ve added halftone as a choice for process mode in the new version of Luban. Which seems like what the grayscale was already doing. It may just be that the halftone does a fixed amount of dots at consistent spacing and size is varied for darkness. Haven’t had a chance to play with it to see what it’s doing exactly.
I don’t use Luban, that’s a true grayscale image from Lightburn that varies power level as it travels.
I’m getting banding because without LASER_POWER_INLINE the M03 command executes planner.synchronize() which waits for motion to stop before changing laser power.
This also applies to M5, which requires stopped motion before disabling the laser.
Even with Lightburn’s overscanning, it has no effect in this firmware because Marlin cannot stop the laser while in motion. This effectively guarantees edges will be darker on fills.
These were printed with a huge overscan, working out to approximately 5mm at the faster speeds.
You can clearly see where the firmware stops at the edges, and the accleration and deceleration from the edges.
The only way to manage it now is to choose speeds very carefully so the acceleration is low enough that the edges are not excessively darker.
Even though the laser is powerful enough to print at a higher speed, for instance, speed row 6 or 7 would be appropriate for some engraving, but cannot be used because of the edge darkening. Row 3 or 4 is the limit, meaning it takes at least 2x as long to complete.
For what it’s worth, speed row 4 was used for the above grayscale sign. Thought it was an acceptable tradeoff of edge darkening, didn’t expect such pronounced banding due to the motion stopping at every power change. Makes sense in hindsight, it will need to be run at speed 2 probably, with max power limited to 60% to preserve dynamic range.
I don’t think you can really use any type of video footage as proof of pulsing or stuttering.
Because you’re dealing with a frame rate on the camera you’ll see things that aren’t necessarily there. Or be hyper aware of something that is that you don’t see with the naked eye. It’s the same as when you try to video a computer screen (especially an old CRT that scans) or LED lights and you’ll see them flicker. There are also algorithms and compression artifacts that phones use that cause it to react strangely to sudden changes in light levels or information.
Your comment with the video mentioned “pulsing and stuttering”. You didn’t say anything about speed. Actually the speed looks to be uneven - like it’s speeding up and slowing down randomly. Hard to tell from the angle and if it’s just an optical illusion. The way to really check that would be to film perpendicular to the travel of the laser. Set up a ruler parallel to the travel and shoot in slo-mo. Then you could easily tell the travel of the laser from frame to frame.
It’s worth noting the start origin is here, since it’s fairly untypical. And Since all of the moves are G91 relative, the touchscreen’s run boundary function will fail to accurately run the boundary.
I’m currently removing the noise from the video so the sound is easier to hear. Will update above when finished.
You can modify the acceleration limits? How? If so, it would definitely need to go up. I wonder though if it’s the laser power change or a change in the move command. For instance, if we leave the power at 100 and do the following will it start and stop therefore causing the same acceleration issues? (I may have already figured this out but don’t remember)
M3 P100
G1 X0
G1 X10
G1 X30
G1 X100
G1 X110
M5
If this isn’t the issue, the way to avoid this would be for the machine to be able to process commands like so (as seems standard in other machines).
Personal Aside:
Again, it will probably be quite some time before I make it back to the laser module. I started with it to get familiar with the machine, but it’s really the least useful tool… almost like a toy at the frequency range and low power it’s at. Good idea starting a new thread addressing the exact issue we discovered from the old one btw.
So funny enough, I’ve pulled the LASER_POWER_INLINE feature from the latest Marlin branch and can now do true grayscale without it pausing. No need for modifying acceleration.
Still working out a bug or two… but initial testing is going well enough.
So, there have been a few patches made to the supplied SM2 firmware. I’ve been playing with the idea of creating a github repo with the current version of SM-firmware - I actually created a local repo on my workstation, initialised it, added 1.7.0.0, committed, erased the tree, added 1.8.0.0, committed, erased the tree, added 2.0, committed. The idea being that this would give me a log of what changed between versions. I could publish this as a project in my github account.
I am not sure of the legality of publishing the source like this into github, but I suspect that given it’s already open source, there shouldn’t be an issue.
This would allow patches like those made by @brent113 and @zauguin to be added, it would also give us a place to track issues.
Because Snapmaker is using code under a GPL license, they’re obligated to make the code public. If you make it public, they have no valid case for copyright infringement, since you’re simply doing what they’re already obligated to. As long as you don’t misrepresent ownership or license, you’ll be fine.
