Velocity Ramping
-
Does the Duet yet do this?
To know if it does or not take a square and laser the square and if the edges are burnt then it doesn't yet do this.
Does anyone know?
-
I think the answer is "Yes, it can do this, if it is told to do so".
As you need to find software that will generate g-code that has lead in and lead out where the machine has time to accelerate and decelerate. Duet on its own only execute the moves other software has planned (like slicer and CAM software does for printing and CNC)
-
Isn't a velocity ramp an acceleration? i.e altering the rate of change of velocity with respect to time.
-
From his post there are two options
- he wants to do vector style laser engraving, in which case he needs the power to decrease as the velocity decreases leading up to a corner.
- he want to do a scanning style engraving where the laser is allowed to accelerate before starting the engraving.
It is my understanding that Duet will do both, but I stopped reading about laser when I saw there is no difference between G0 and G1 moves as my prefered "CAM" for laser uses G0 for moves with laser off and G1 Sn for moves with laser on.
-
@bearer Ahh, so he wants to ramp the laser power as function of movement velocity. I know nothing about lasers, hence my confusion over the terminology. Thanks for clearing that up.
-
To be fair the post isn't very clear to begin with.
But yes, the goal is a consistent power level per surface area independent of speed.
Either achieved through adjusting power as speed varies or ensure there is enough lead in to allow constant speed and just switch laser on/off according to what needs lasering as the head passes by.
The first is better for engraving simple vectors, the latter is faster for complex art or raster graphics. Or a combination of the two.
-
@bearer said in Velocity Ramping:
It is my understanding that Duet will do both, but I stopped reading about laser when I saw there is no difference between G0 and G1 moves as my prefered "CAM" for laser uses G0 for moves with laser off and G1 Sn for moves with laser on.
Sorry to go a bit off topic, but what's your prefered CAM for lasering?
-
I use "CAM" in the most liberal sense, but flatcam and inkscape from the last millennia. Could be recent versions support G0 moves with laser on, but grbl+cnc shield for the nano+tmc2130 does a very good job for the price so unless it breaks I'm unlikely to upgrade just because.
(My little cnc router on the other hand is now begging for a duet:)
-
RepRapFirmware does not yet ramp the laser power up during acceleration and down during deceleration. It's on the to-do list.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Velocity Ramping:
RepRapFirmware does not yet ramp the laser power up during acceleration and down during deceleration. It's on the to-do list.
This is why software like LightBurn recommends against the Duet until it can handle this at the minimum. The G0/G1 issue (that was mentioned earlier) is another issue.
-
@devleon said in Velocity Ramping:
@bearer said in Velocity Ramping:
It is my understanding that Duet will do both, but I stopped reading about laser when I saw there is no difference between G0 and G1 moves as my prefered "CAM" for laser uses G0 for moves with laser off and G1 Sn for moves with laser on.
Sorry to go a bit off topic, but what's your prefered CAM for lasering?
Lightburn and as the creator told me Duet just couldn't do the most basic, and very needed, function of Velocity Ramping as DC42 confirmed. Another issue is the G0/G1 deal mentioned above.
If the Duet EVER can do both then I can toss my Ruida controller because I do, very much so, dislike it though I was told it will be faster than a gcode sender so 1000mm/s on a Ruida is no problem but on something like Duet is probably not going to happen though I don't know about that personally.
-
@darkalchemist said in Velocity Ramping:
@dc42 said in Velocity Ramping:
RepRapFirmware does not yet ramp the laser power up during acceleration and down during deceleration. It's on the to-do list.
This is why software like LightBurn recommends against the Duet until it can handle this at the minimum. The G0/G1 issue (that was mentioned earlier) is another issue.
G0 is defined as rapid (uncontrolled) move. Programs that generate GCodes for laser cutters should most definitely not use G0 moves to do cuts. They should only use G0 moves for positioning the laser head, with the laser odd.
As an engineer with experience of safety critical systems, I'm amazed that the writers of software to generate GCodes for laser cutters appear to disregard safety completely. It is inexcusable that when the S parameter is used to specify laser power on a G1 command, the firmware is expected to treat the S parameter as sticky. IMO, this is such an obviously unsafe situation that in the event of an accident in the UK, if the vendor of the laser cutter concerned used such software then they are open to prosecution by the UK HSE.
Being open source is great, but open source is not an excuse for failing to consider safety.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Sorry for hijacking again, but I'm currently in the process of adding a 500mW laser to my 3D printer, and I want to evaluate what kind of software I can use that works with the laser mode (M452) of the Duet.
I have not tried LightBurn, but many people suggested LaserWeb4. I setup a basic profile, and chose the "Laser Cut" option, and it generates GCode like this:
G1 X33.73 Y16.07 S255.00 F3000 G1 X36.89 Y19.23 G1 X36.94 Y19.30 G1 X36.96 Y19.38Is this what you mean with expecting the S parameter to stick? Will this only turn on the laser for the line has has the S parameter, or also for the following lines? The wiki only states that G0 moves will never enable the laser.
If this above is not supported by Duet (and I can see that for safety reasons), do you have any experience with software that does it right?
-
Come think if it the only difference with G0 moves is they happen at different default/remembered feed rate, and the spindle isn't affected on the CNC so it would make sense for laser software to explicitly turn off laser instead of using G0.
Flatcam should be doable to at least make G0 S0 code, for when the laser mode start taking acceleration into account for the power output.
-
@devleon said in Velocity Ramping:
@dc42 Sorry for hijacking again, but I'm currently in the process of adding a 500mW laser to my 3D printer, and I want to evaluate what kind of software I can use that works with the laser mode (M452) of the Duet.
I have not tried LightBurn, but many people suggested LaserWeb4. I setup a basic profile, and chose the "Laser Cut" option, and it generates GCode like this:
G1 X33.73 Y16.07 S255.00 F3000 G1 X36.89 Y19.23 G1 X36.94 Y19.30 G1 X36.96 Y19.38Is this what you mean with expecting the S parameter to stick? Will this only turn on the laser for the line has has the S parameter, or also for the following lines? The wiki only states that G0 moves will never enable the laser.
If this above is not supported by Duet (and I can see that for safety reasons), do you have any experience with software that does it right?
Laserweb was horrible and I would not wish that on anyone. Poorly written in Java I believe while Lightburn is written in C++ and trust it matters greatly.
To everyone I keep forgetting to check back on this thread because this is the first forum I have ever used that didn't have a send email for replies option. If it does I couldn't find it.
-
@dc42 said in Velocity Ramping:
@darkalchemist said in Velocity Ramping:
@dc42 said in Velocity Ramping:
RepRapFirmware does not yet ramp the laser power up during acceleration and down during deceleration. It's on the to-do list.
This is why software like LightBurn recommends against the Duet until it can handle this at the minimum. The G0/G1 issue (that was mentioned earlier) is another issue.
G0 is defined as rapid (uncontrolled) move. Programs that generate GCodes for laser cutters should most definitely not use G0 moves to do cuts. They should only use G0 moves for positioning the laser head, with the laser odd.
As an engineer with experience of safety critical systems, I'm amazed that the writers of software to generate GCodes for laser cutters appear to disregard safety completely. It is inexcusable that when the S parameter is used to specify laser power on a G1 command, the firmware is expected to treat the S parameter as sticky. IMO, this is such an obviously unsafe situation that in the event of an accident in the UK, if the vendor of the laser cutter concerned used such software then they are open to prosecution by the UK HSE.
Being open source is great, but open source is not an excuse for failing to consider safety.
G0 isn't used to do cuts, it is only used for positioning between cuts, so your rant seems misplaced.
-
@bearer said in Velocity Ramping:
Come think if it the only difference with G0 moves is they happen at different default/remembered feed rate, and the spindle isn't affected on the CNC so it would make sense for laser software to explicitly turn off laser instead of using G0.
Flatcam should be doable to at least make G0 S0 code, for when the laser mode start taking acceleration into account for the power output.
This is what I was told by the Author of LB - By having G0 turn the laser off you save a shitload of beam management code.
-
Not sure how that actually make sense, if you have to determine wheather to send
G0orG1I fail to see how it makes any difference if you ouputG0orG1 S0other than the resulting gcode will be larger? -
@bearer said in Velocity Ramping:
Not sure how that actually make sense, if you have to determine wheather to send G0 or G1 I fail to see how it makes any difference if you ouput G0 or G1 S0 other than the resulting gcode will be larger?
LB: Yeah, pretty much. On a decent processor it might not matter, but if you're on an 8 bit, the extra processing time and extra bandwidth adds up. Parsing S0 is parsing a floating point number. Parsing G0 / G1 is parsing an integer. Converting ASCII to float on an 8 bit chip takes a lot longer. Not a huge deal.
That is what he had to say about it and I must admit I agree with him but I am anal like that as I remember the old days of 1.022730 mhz 8 bit 6510 Commodore 64 ASM/ML programming. While even the Arduino is not at that stage of slow (so slow somethings had to blank the screen to gain more processor power back) it isn't that far removed either. The Duet has the horsepower to do it, I presume, so not a huge deal as he said.
Getting back to the main deal breaker is the lack of the Velocity Ramping which the Ruida controller has. I am looking for a replacement to this controller that can do the ramping (it is a requirement) and can do 1000mm/s without batting an eye.
-
Right, I thought the problem was the PC software output, not the controller interpreting the g-code, but I can see the difference there yeah.
Being able to have cnc, printer and laser on the same hardware platform would be nice, for me it'll never be the same machine anyway.
