search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.02k stars 1.6k forks source link

Scale spindle PWM (Laser power) by acceleration? #15

Closed jsb1 closed 7 years ago

jsb1 commented 7 years ago

What i want is scale Laser power down while accelerating / deccelarating. I think this would solve the problem of deeply burned edges and other small figures. It can be easily done in st_prep_buffer(). Formula would be: new PWM = calculated PWM * [current_speed from acceleration code] / reference speed. (simple version, there should be a configurable minimum) What would be the best value for "reference speed"? I suppose the output of plan_compute_profile_nominal_speed() would be OK, but I'm not sure.

jahnj0584 commented 7 years ago

Is it not easier to just cut at a speed without acceleration time?

On Oct 20, 2016 10:20 AM, "jsb1" notifications@github.com wrote:

What i want is scale Laser power down while accelerating / deccelarating. I think this would solve the problem of deeply burned edges and other small figures. It can be easily done in st_prep_buffer(). Formula would be: new PWM = calculated PWM * [current_speed from acceleration code] / reference speed. (simple version, there should be a configurable minimum) What would be the best value for "reference speed"? I suppose the output of plan_compute_profile_nominal_speed() would be OK, but I'm not sure.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/15, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDBUbDhHPawx_5JTjXi0cg7d0r6XMks5q12qUgaJpZM4KcHir .

chamnit commented 7 years ago

@jsb1 : That's something easy to add to Grbl. I had in my notes, but it got buried amongst the dozens of pages of todo's. However, the main issue I can see is how to set the scalar for speed to power. This may not be linear.

The first thing to try is to assume a constant laser output power per mm traveled. So the spindle speed divided by the current speed (S/F) must be the same throughout a single line motion. Any time the feed rate is lower, the spindle speed must also go down by a proportional amount.

EDIT: The reference speed would be the nominal speed for the block (F_0) and the equation for updated PWM would be S = S_0*F/(F_0), where S_0 is the programmed spindle speed and F is the current speed. This could also get complicated if you have to account for spindle speed overrides. Do you increase the power per mm? Or do you scale it with the spindle speed override, feed override, or both?

If this indeed works better, then we can talk about adding it officially to the main repo here. If not, then there will need to be more testing to determine how nonlinear it is, how so, and how many configuration options users need to dial it in. This is may get messy, if this is the case, which probably why I buried the note to add this long ago.

jsb1 commented 7 years ago

@chamnit : I think spindle and speed overrides are global factors and are not affected. The suggested feature is just a correction wihin the planned block. I tries to keep power per mm constant in current move. Already tested that in v0.9: https://github.com/jsb1/grbl Additionally I introduced a minimum to take some tool nonlinearity into account (think of drag knives) so my formula is like that: let 0<= M <=1 be the minimum factor. S = M * S0 + (1-M) * S0 * F / F_0 (I used M scaled by 1000 to make it integer) That seems to work well with m=0.1 on my laser. Essentially it means a minimum of 10% power when starting from zero speed. Just remembered: I read something about power correction in Smoothieware. I'll try to figure out what they are doing. P.S.: All changes I would have suggested are already in v1.1 :+1: Especially the squared feed rate in pl_block caused some trouble.

jsb1 commented 7 years ago

@jahnj0584 : Sorry, machines cannot go full speed in some cases. There are some laws of physics to obey. Straight lines can be cut by accelerating before switching the laser. But what about small arcs?

jsb1 commented 7 years ago

@jahnj0584 : thinking of it, yes it is possible. Suppose you cut a rectangle with rount edges : some line + 90 deg arc + next line To cut at constant speed, gcode must do this

  1. go before line
  2. accelerate to line speed
  3. cut line
  4. decellerate after line
  5. go back to a place before arc
  6. adjust laser power
  7. accelerate to arc speed
  8. cut arc
  9. go back before next line
  10. adjust laser power
  11. accelerate to line speed
  12. cut line

Do this 4 times for complete rectangle. A lot of useless time and motions! To avoid that there is a forward looking planner in grbl. It slows down to arc speed while cutting the end of the first line. After the arc it accelerates to full speed while cutting the next line.

chamnit commented 7 years ago

@jsb1 : The squared speeds in the planner are there on purpose. They reduce the number of floating point operations by an non-trivial amount. As you may know, floating point is very expensive on an 8-bit AVR. In v1.1, those particular operations were no longer there, so the speed square were reverted back to speed.

There is already a minimum factor in Grbl called SPINDLE_PWM_MIN_VALUE, which will the same thing as your M variable.

With overrides, I meant that how should both the feed and spindle speed overrides handle power/mm? Meaning only one of them should be able to alter the power/mm, while the other alters cutting speed only. You'd probably want feed overrides to alter only cutting speed keeping power/mm the same, while spindle speed override would directly scale power/mm. In addition, you have to consider how to handle max/min of the motion and spindle speed. What happens if you are burning a raster image? Scaling power/mm would truncate the upper or lower bounds of the laser power causing the image to lose dark or light detail. How about other types of lasers? Do they behave the same way? How do you best handle all of these scenarios? These are the questions I had in mind when I looked into this before.

In practice, a good laser cutter operates with a very high acceleration, like a 3d printer does. So you don't have to deal with these types of problems. I feel like if Grbl introduces constant power/mm option, then all of these things really need to be worked out. Perhaps, they can, but I still have a lot of questions.

jsb1 commented 7 years ago

Found it in Smoothieware's Laser.cpp: As I understand there is a fixed minimal PWM which configured but not scaled by gcode. The rest of PWM range is proportional to S0 * F / F_0. Seems to be OK: https://github.com/openhardwarecoza/LaserWeb3 I have no idea which formula is better: smoothie or mine?

chamnit commented 7 years ago

@jsb1 : The formula you wrote earlier and the S0*F/F_0 is the same, if you account for minimum PWM. This still doesn't answer what the standard for handling overrides on lasers is. I'm just getting into laser cutters, and I think this is still undefined.

jsb1 commented 7 years ago

@chamnit : Sorry, I did not see your answer before sending last comment.

About overrides: I think it is dangerous to implement too many automatics here. I have only a 2.5W laser. Normally I run it at full power and adjust speed to control cutting depth. But a with a 100w tube and thin material motion speed can be the limit and power has to be reduced. There are different use cases. I think it is better to keep things simple. Linking speed and power can be optional - and implemented later.

to max/min limits: energy (not power - sorry, my fault) per mm should be calculated from gcode (after applying overrides) and always kept constant within a single command. Same as extrusion length per moved mm on 3d printers. When motion limits are applied, power should be scaled. Really cool would be slowing down motion when calculated maximum power requirements cannot be fulfilled. That would automagically solve the problems with too high or low overrides.

I have no big experience with firmware speed limits. Normally I dont let my machines run into them. You never know what happens when they are hit...

formula: I think they are not the same: my minimum is multiplied by incoming S-value. Smoothie's lower limit is independent from gcode. Maybe it is better - and saves one multiplication.

chamnit commented 7 years ago

@jsb1 : With overrides, I've been thinking about it all day. Talked to our machinist about it too. I think the best way to implement it is to define the spindle speed override as a laser power/mm adjustment, while feed rate overrides is a feed adjustment only that maintains the laser power/mm. This provides you with two independent ways of altering how your laser is cutting without too much confusion.

However, I think it'd be a good idea to look at how some professional laser cutters handle overrides. I'm not entirely sure that they normally have any overrides or not.

With max/min limits, I agree for the most part, but this could be a slippery slope. Grbl can always try to keep the programmed laser power/mm. If the feed can't be achieved, Grbl will try to decrease the laser power proportionally. However, this could lead to some weird operation in certain situations.

On a CNC lathe, there is something called constant surface speed. Depending on the radius of the cut, the lathe spindle will automatically adjust its RPM to maintain the surface speed of the cutter. Typically, you'll see that when the RPM is maxed when you are cutting near the lathe axis, the lathe just keeps the same max RPM and same feed rate to finish the cut. It doesn't automatically slow down the feed of the cutter to compensate. It's generally the job of the machinist to account for this.

That said, to make the power/mm adjustments all automated internally by Grbl could make it less useful and harder to know how its going to behave. I'm not entirely sure whether not doing anything different when you hit a feed or speed limit is better either. I'll have to think more about it over the weekend.

As for the formula, ok. It's a little different. FWIW, Grbl also sets the lower limit independent of g-code. I think what you are asking for is some way to alter the linear model, or more configurability of the spindle output. You're not the first to ask this, but it's on my to-do list. I think this is a separate issue from constant laser/mm and overrides. I'd rather set this aside since it's independent of the others.

jsb1 commented 7 years ago

@chamnit : With overrides, I can ask a friend at a university lab what their cutters are doing.

With formula, I agree, tool linearization should be another discussion.

The CNC lathe is a different case: The cutting speed has less influence on the resulting form of the workpiece. Either it works or tools are breaking. But a laser engraver is cutting significantly deeper when speed is going down.

A different point of view: safety Grbl has limits to protect mechanics: dimensions, speed, acceleration. What is dangerous on laser cutters? low speed! Workpieces can catch fire and base plates can get burned. Whenever grbl decides to slow down motion it is beyond users control. I think It should also scale down laser power.

chamnit commented 7 years ago

@jsb1 : Yes. Safety is a huge concern. It always has been, but Grbl can't account for every single scenario on every machine, even if the machine is ill-suited for the task, like a using a CNC with a very slow acceleration and adapting it to do laser cutting. That's not a really good idea anyway.

Like I said before, providing a constant laser power/mm has been on my list of things to add to Grbl. It did not make it into the v1.1 beta release, but it should be clear by now that we are trying to determine the essential parameters of whats needed. If it makes sense to, then I'll install it. When I say, if it makes sense to, I mean there is a clear, simple implementation that will govern its behavior. My gut feeling is that this can easily get out of hand with accounting for all types of rare situations and nonlinearities.

jsb1 commented 7 years ago

@chamnit : I mentioned safety because it points into the same direction :-).

Ok, thank You for discussing! I will do the minimal change I want for my laser: scaling power by (current speed) / (nominal speed after applying overrides). When I'm done with testing, I will offer a pull request. OK? Should that feature be configurable at:

One thing is disturbing me a little. You are talking about constant power / mm. What I want is constant energy / mm. energy / distance = power / speed (at constant speed) or in units: Joule / mm = Watt / (mm/s) Just to be exact.

chamnit commented 7 years ago

@jsb1 : Laser power (watts = volts*amps) is usually used to describe the cutting capability and is what scales with spindle PWM output. If you really want to be overly technical about this highly moot point, then, yes, energy/distance is the correct units of measure, but I think the more apt term is watts/rate. Either way, we are trying to address the same problem.

jsb1 commented 7 years ago

@chamnit : please excuse. I know that we are talking about the same thing. That is my training in nature science - a long time ago: Always be precise with units!

You might ask why I'm insisting on that feature. Well - I think that laser mode is not so much worth without it. I will send pictures when I am done. But first I have to solder a bit. The Laser on that chinese hardware is not really controllable. Currently I have a very small pwm range where I can set power. And it seems to depend on temperature (which temperature? environment? laser module? switching transistor?)). I think it is nearly impossible to compensate that with software...

chamnit commented 7 years ago

@jsb1 : There is no need to keep reminding and insisting. Like I said before, I fully understand the why. But keep in mind that it's far less of an importance if the laser is on a properly built machine that can move with high accelerations, as most professional CNC lasers are built to do. I don't work on this project solely to help people fix and adapt their poorly-designed and built hardware. If I have the time, I will, but it's not my priority.

That said, I did have some time to look at how to implement it. Apparently I have everything in place to do so easily. The equation is also simple, assuming a linear relationship: S_updated = (spindle_speed_ovr * programmed_spindle_speed) * (current_speed / programmed_speed). I can probably get this installed tonight and tested soon after.

There were two questions that popped up:

chamnit commented 7 years ago

@jsb1 : Ok. I pushed Grbl's new dynamic laser power feature . You'll need to uncomment the #define at the bottom of the config.h file to enable it. It's called LASER_CONSTANT_POWER_PER_RATE.

It's experimental, meaning that how it should behave hasn't been fully established or defined. So things may change, based on user feedback. One thing to look out for. The laser will remain off when the machine is not in motion, even though you enabled the laser with something like M3S1000. It'll only turn on, if it's in motion. I may change this to turn on to the minimum PWM output whenever enabled to help indicate that its on.

Feed rate overrides(FRO) do not alter the laser power/rate. Laser power will scale with FRO to keep it consistent. Useful if Grbl starts to stutter. You can slow down the job and the laser should keep burning the same. (There might be some slight variation due to nonlinearity in the laser output).

Spindle speed overrides(SSO) directly alter the laser power/rate. So it'll increase or decrease laser power and account for the power change, if the machine slows down.

With both FRO and SSO behavior set like this, you should be able to tune your job dynamically and in real-time, even if the laser power is nonlinear.

jsb1 commented 7 years ago

@chamnit : thank You very much! Currently very busy. I will test ASAP!

jsb1 commented 7 years ago

@chamnit : I'm really sorry that I could not give You any feedback yet. But it seems that others have tested - very good. I am very busy in "real world" until next year. And my laser is currently in rebuild state. Blown up the diode, adding water cooling, a new PWW driver, waiting for spare parts... But I have an interesting project idea and would like to discuss it with you. Will be my next issue...

With best regards,

Jörg

AxelGUILLAUMET commented 4 years ago

Dear friends I have exactly the same problems there!

https://github.com/arkypita/LaserGRBL/issues/1044

https://github.com/grbl/grbl/issues/1637