@techguy682 @vicious1 I have two pairs of these. According to their graph, at ~450nm they are ~OD7 .
https://www.amazon.com/190nm-550nm-800nm-1700nm-Wavelength-Professional-Glasses/dp/B085XZJQD3/ref=sr_1_2_sspa?dchild=1&keywords=Professional%2BLaser%2BSafety%2BGlasses&qid=1606105302&s=hi&sr=1-2-spons&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEzU1NCUVFDTU80VkM5JmVuY3J5cHRlZElkPUEwMTg5NTM1MVRRNkNLQTE0VEhGUSZlbmNyeXB0ZWRBZElkPUEwMDgwNTk5M0FCTVI3UlUxVDRKRiZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU&th=1
1 Like
But overscan is a setting in cam, right? So it would be better for other cam programs if it wasn’t needed.
I am mostly just basing this on the fact the grbl folks seem to love it. I have only turned my laser on once.
Yes. It can be enabled I think. I would have to test it more. The reason I did not enable it is vectors and rasters actually look pretty good even without overscan and I am doubting the 8bit boards can use it as the basic version messes up vectors.
I am thinking the glitches is a Marlin issue that needs to be fixed so for now maybe just enabling the basics and getting more to test it is a good solid first step to figuring out the actual issue.
1 Like
Looks like the bugfix branch is good to go for the SKR in Marlin builder. Now that I found the right command. That was the branch I was testing in so it is okay that the current branch is borked.
Maybe, but I think the SKR has more than enough power. Smoothie has a laser specific firmware that writes the gcode a different way to add more commands per buffer line, and it maxes out at about 300mm/s at 300 dpi, so the SKR is probably fine with a diode laser running 27mm/s at 133dpi.
1 Like
If it helps my SM2 laser running marlin has the same glitch issues when running at high speeds and it uses a 120mhz controller, so I think its a marlin bug.
2 Likes
I’m a little lost. The glitches are only in 2.0.7.1 or the glitches are only in bugfix?
I only tested bugfix. The current release branch will not compile, something about the pins or pwm.
#error “Features requiring Hardware PWM (FAST_PWM_FAN, SPINDLE_LASER_FREQUENCY) are not yet supported on STM32.”
Hmmm. Not cool. I am guessing there is some way to configure it to work with 2.0.7.2 with a software pwm or something. But I don’t think we are in a tight spot, and since it is under development, it’s NBD to test everything with the changes after these.
It’s okay if the next version bump does not happen soon we can just have the SKR track bugfix until it does…or link people to the laser build if they want to try it out. Marlin bumps have been happening pretty frequently.
How-To: Modify Marlin to control a laser with an SKR Pro you can likely get around the PWM pin thing with my instructions
Can you post your source for this? My SM runs on a STM32 clone and I would like more details to give to some others in that community.
1 Like
Going with your gut what do any of you think could be causing this? Anything I can test?
How fast can we expect the commands to come off an SD card, to the board? Changing the buffer size could help, maybe, the downside being pause or stopping regular gcode while cutting will take longer, does anyone do that? If I have to do something it involves an emergency power cut.
The thing that throws me is sometimes the glitches are with the laser off. If it was a buffer issue it is meant to slowdown, that would result in the common burn marks. But on some of the tests the glitches are blank spots not burn spots. This leads me to believe it is somehow a planner issue.
That is very strange. I am not sure what could explain that. Is that bugfix or the 2.0.7.2 build?
1 Like
bugfix.
@vicious1are the glitches random or repeatable if you repeat the same print?
One idea, is the 3.3v pin on skr enough to reliably pull the signal up. Yes it is above ttl logic high but not by much. Solution may be op amp or optic isolator to shift from 3.3 to 5v. Random guess though.
1 Like
Random.
Isn’t the threshold like 50% power not the full 3.3V?
In the firmware do you have LASER_POWER_INLINE_TRAPEZOID_CONT in uncommented ? It is commented out by default. See https://github.com/MarlinFirmware/Marlin/pull/15335#issuecomment-536350008 for speeds and comments on why LASER_POWER_INLINE_TRAPEZOID_CONT was added.
There tests were getting black burns where there should have been greys.
1 Like
Tried it all three ways a few times and several values for the steps, 2, 10, 20, 0.
There is another PR having to do with lasers and it seems they might have optimized it a bit more. I didn’t fully understand it but it looks like there might have been some random issues there as well.