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.
I’m a little lost. The glitches are only in 18.104.22.168 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 22.214.171.124 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.
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 126.96.36.199 build?
@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.
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.
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.
Most of those looks like dark burn marks, followed by large gaps. Is it possible this is mechanical? Maybe it is sticking and then when it get free, it takes off?
CHECK THE GRUB SCREWS
Tangent. I just ordered a 6 pack controller to do some speed tests with my build and a laser. Kinda excited, kinda not ready for any more testing. Decked out it is about the same price as the SKR bundle.
AAAAAHHAHAHAHA It better not be.
Some have that some don’t.
TTL is logic high above 2.0v, that assumes that the 3.3v skr gets above 2.0v quickly, it also assumes no noise.
If the laser is using CMOS circuits for pwm then logic high is 70% of VDD which is 3.5v logic high so things could just work.
My odds are on a planner problem though.
So, I guess that leads me into my bonehead mistake. I wanted to check the signal for goofy shapes, or odd timing.
How the heck did I kill two different SKR boards with my scope? I put the probe on the signal pin, and lazily the input negative pin. Then on the second one I was convinced I popped it with carpet static or something I hit the signal pin and the boards ground plane.
What the heck did I do wrong?
Neither board has USB or LCD functions, but if I re-flash it it changes the file like it should.
I don’t have an answer for you, but those pins have no buffering, no protection, they’re a straight shot to the STM chip.