To make it official…you guys are amazing how you learn all this stuff escapes me but I’ll try…
[attachment file=88413]
2 Likes
Okay, call me crazy. I swear I got it from somewhere - the LCD library include instruction. But it clearly wasn’t the Marlin info on the site. All is right in the world it seems.
I think that’s a good choice. The larger 40mm x 40mm version is a what fits on the 3.5 watt lasers… and it seems to work well.
[attachment file=88432]
2 Likes
First run. Not too bad. I slowed it down to about 90% at the feet, then 80% around the head. This is on regular plywood, the grain probably has something to do with the unevenness of the burn. I think anyways. Thanks to everyone in this thread who has already put in so much time and effort.??
So I’m not having much success in doing images of my own. Would anyone mind sharing a good starting point for the settings in Image2gcode??
ok, that is right fix
this fan frequency updating reduction had been added by this commit
i don’t know why.
the problem is that planner.check_axes_activity();
performs 2 diffrent actions at same time
- check steppers inactivity and disables it
- does actual writing of fans PWM values to output ports.
to be honest removing this 10Hz reduction is just workaround. because syncronization between fans and motions still weak.
facts:
- M106 writes a value to global array fan_speed
- whenever planner populates new block in the queue it copies values of fan_speed to local array fan_speed of the block. looks ok - a motion command that followed to M106 will have new fans speed.
- the planner.check_axes_activity() applies values from global fan_speed when queue is empty and takes values of fan_speed of the last (WHY LAST???) enqueued block if the queue non-empty.
that’s it
So, it’s still not setting the fan speed from the commands in the buffer? Maybe that used to work and something else broke it? I found that commit too, and I’m surprised it’s from nov 2017. That seems like too long ago.
No. You may search “->fan_speed” and".fan_speed" across entire project. Only place where fan speed taken from a motion block is that check_axis_activity. And it looks like this code may apply fan speed from the future
Yeah, I’m wondering if that used to be different. Like it used to be set alongside motion. I’m not looking at the code, just wildly guessing :). It seems odd that this could have been broken for that long, so I’m wondering if another change moved responsibility or setting fan speed from the right place to this check_axis_activity about 6 months ago.
Honestly it’s not broken. In terms of fans control. It just not fully applicable for laser that requires precise synchronization. Marlin need to be extended to handle lasers properly.
If it’s picking future fan values, then that’s broken. A single gcode move could take minutes.
It’s arguing nomenclature though. Lasers should be supported. It doesn’t have to be perfect, but it should be better than one update every 100ms.
In theory. But for 3d printing it’s damn rare case. So no one complaining. cooling fan enabled/disabled a few sec earlier - who cares? It’s just invisible for average user.
Okay… for once I decided I might as well be as up-to-date as everyone else. Edited the Bugfix-2.0.x version of the firmware by commenting out the infamous 4 lines in Marlin.cpp and reran my two gcode files.
Interestingly, I thought the motion seemed fractionally smoother than the old firmware that I had been running. It appears that wasn’t just a figment of my elder imagination. The “shades of gray” gcode is distinctly sharper along the block edges… new firmware on the left, old firmware on the right
[attachment file=88546]
[attachment file=88547]
I think I’ll keep it…
– David
3 Likes
Sweet! If we could just find where the fan changes are making the darn thing accelerate we would be in business. I tried to keep my travel and burning speeds the same to not trigger accelerations but it still happened so it has to be the fan speed, which seems crazy to me.
Oh that is cool! Thanks for sharing that. Over this weekend I upgraded to Marlin 2.0 had the issue and then reverted back to my old 1.1.5. Since Ryan had found the code in the Marlin.cpp I decided not to even post my simple finding. I was going to stay on the old version until I saw your post. Thank You. And also thank you for all the time you spent debugging this issue.
When you say the problem is the acceleration I don’t understand what you mean? Are you talking about the left and right darker images in the shades of grey laser burn? Those are not a firmware issue. Those are caused by the image to Gcode app. It is causing the MPCNC to work on one small square at a time so it is going back and forth in each square. That is why you see the acceleration burns darken in each square. If Image to Gcode worked like Image2Gcode and went the entire length of the X per each pass then most of those would go away. If it also implemented the “Overscan”, “Accel Buffer”, or whatever else we called that feature then all of those would dissapear completely. It is possible to accomplish the same result with changes to the firmware but that would involve more work like what you all discussed earlier. Now that I think about it that is probably what you meant. That it would be better to get that feature coded into the firmware so it wouldn’t matter what software wrote the Gcode it would just work. I fear that may cause problems with Vector images used for cutting out shapes. But I have had no experience with laser cutting before this so I don’t know if my fear is founded or not.
I think Ryan is referring to the problems with the M3/M5 commands. They insert a synchronization step in the buffer that means every time the laser changes power, the machine has to stop, which means accelerations.
Thank you, Aaryn, for the kind words. I’m confused by these statements, however…
Unless I’m misunderstanding what you are saying (which is quite possible), the MPCNC is clearly scanning the entire image from side to side… starting and stopping at each block boundary. The MPCNC is not handling the burn one small square at a time… but starting and stopping with each power change, as Jeff said, and, it appears, experiencing accelerations that darken the edges until it reaches full speed.
[attachment file=88588]
– David
Well look at that. You are absolutely right. I stand corrected. But in the Gcode file you uploaded it is using M106. So is it really just a problem with M3/M5 like Jeff said or is it also a problem with M106/M107. Because when I was running marlin 1.1.5 it wasn’t a problem with M106/7.
now I want to run the shades of grey with both firmware versions to test.
In my limited understanding of what the real problem is, it makes no sense that a fan, controlled by M106/M107, needs to undergo the same delays and/or accelerations as a spindle… yet it appears it does. It makes no discernible difference when controlling a fan but, when used to control a laser, it is discernible and makes a difference.
1 Like
Exactly. I am just not fluent enough in the firmware to even see where the fan (M106, or M3) gets into the planner or buffer or wherever it is. Maybe I will have another look right now.