Oh, I see. It’s only checking to see what speed the fan should be at 10Hz.
So, either:
a) this is a bug. Doubtful, its doing what the commwnt says.
b) this isn’t thw right way to laser. But the laser mode stops for every move.
c) this should be a parameter. I think either adding a CONSTANT_FAN_CHECK configuration or setting the 100UL by a condiguration value is reasonable. It’s worth a PR.
Heath, the funny thing to me is Garfield with that look on his face watching you “skip like a school girl”.
Sounds like
b-This would be the most proper thing to fix.
c-Not sure why this was added in the first place.
Either there, or wherever those functions are being called. That should work.
Maybe @bcdcmcnamara (BT) or @guffy would like to take a crack at the PR. Although you’re doing great so far Ryan.
So why is David’s working right, but the rest of us seem to be having problems. I’m running ramps and the same laser he is. It’s late here, and I’m burned, maybe I’m just missing something…?
He is using a previous version of marlin, before the delay was added in.
Feel free to have a crack at it. I am definitely not touching it this weekend.
Ok, i read the thread. And what i think.
Laser engraving is special case and may be marlin just not ready to serve it. Old versions works relative good just because of some luck.
Let’s thinking logically.
Activities that drive laser should be carefully synchronized with motion and i think should be added to motion queue.
3d printer works precisely because the extruder is stepper! It driven by same queue and isr as axis steppers.
If cooling fan or hearer turned on ± few mm it doesn’t matter so the firmware doesn’t care.
M3 s/m5 for milling assumed a few sec pause so this pause could be enough to flush motions queue.
M3 o doesn’t care about motions at all. Yes, i had reccomend it to use, but now i see that probably things not so easy as i thought.
That’s it at the moment.
Will check the code, maybe will say something additionally.
And maybe it’s a time to involve marlin developers
The firmware is the problem… the board, laser, and gcode file are fine. What version of the firmware are your running?
How do you have your RAMPS and laser connected? On my RAMPS, I have the D9 fan output (a +12v PWM signal) reamapped to pin 44 (now a +5v PWM signal) to feed the TTL modulation input to the laser. The M106/M107 gcode commands now control the laser’s power.
Pictures help.
– David
Guffy,
Ideally, similar to grbl’s laser mode, there wouldn’t be any changes to acceleration because of the laser, and the changes in acceleration would finely tune the laser power. This would be a bigger change, but it would be awesome. I don’t think we need to deaign it either, because grbl already has. IIRC, there is a min on laser setting, and when the acceleration is reducing the speed by X percentage, the laser power is reduced to X times the difference between the current set point and the min. The math isn’t hard, but finding when to set it, and what the acceleration reduction is (over all axes) is necessary.
I’m sure the main devs would be able to whip it up.
There are a lot of marlin laser machines out there, and I’ve been impressed with how much Marlin has adapted to corner cases.
I agree thay fundamentally, the current spindle stuff is the wrong fit. So it the fan.
That’s talking about the “right way”. There’s still the “Right Now” options. If bastardizing the fan or spindle options makes more sense, then that’s still a worthwhile configuration.
If Heath would burn the Garfield image on a mirror… he could see himself jumping and skipping around like a school girl 
[attachment file=88308]
[attachment file=88309]
We were playing around with the Garfield image and etching mirrors, a couple of years ago, over on my FliteTest thread…
– David
Shoot, this is complicated. Besides better timing, my bigger laser always overshot the raster image to allow for accelerations. So this could be a software fix, before you get to excited Heffe, This would not help with vector art…but with vector art a little darker near corners usually is not an issue. For through cuts no big deal. If you add a laser power curve (I doubt a laser powers linearly) to sync with accelerations then you would need a way to tune it.
So get the laser working as is, and try to get the software fixed, or really try to get it all in the firmware?
[attachment file=88333]
[attachment file=88334]
I am right behind you guys, just another few months. 
I lied. Woke up too early so I tried pulling out all the M3/5 related delays. That didn’t change anything. I really don’t understand the planner enough to know why it still stops each value change.
Someone else must be working on this. I wonder if there are open prs about it.
Am I understanding this correctly? To get the laser working in the Marlin 2.0 code, comment everything except that one line? So it would look like this?
Three lines commented out in Marlin.cpp
// Limit check_axes_activity frequency to 10Hz
// static millis_t next_check_axes_ms = 0; //commented out for mpcnc-laser
// if (ELAPSED(ms, next_check_axes_ms)) { //commented out for mpcnc-laser
planner.check_axes_activity();
// next_check_axes_ms = ms + 100UL; //commented out for mpcnc-laser
Three lines commented out in planner.cpp
/**
* Maintain fans, paste extruder pressure,
*/
// void Planner::check_axes_activity() { //commented out for mpcnc-laser
// uint8_t axis_active[NUM_AXIS] = { 0 }, //commented out for mpcnc-laser
// tail_fan_speed[FAN_COUNT]; //commented out for mpcnc-laser
Because if I do that, the compile fails very quickly with this error:
Marlin.cpp:31:20: error: Marlin.h: No such file or directory
compilation terminated.
exit status 1
Marlin.h: No such file or directory
Just the ones in Marlin.cpp
Removing the comments in the lines in planner.cpp and compiling again, I get the same error.
