Velocity Ramping

dc42

@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.

devleon

@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.38

Is 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?

A Former User

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.

DarkAlchemist

@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.38
Is 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.

DarkAlchemist

@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.

DarkAlchemist

@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.

A Former User

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?

DarkAlchemist

@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.

A Former User

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.

dc42

@darkalchemist said in Velocity Ramping:

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.

You haven't found it. Click on your user icon, which is at the top right of the top bar if you are viewing this forum on a PC, then select Settings.

dc42

@darkalchemist said in Velocity Ramping:

Getting back to the main deal breaker is the lack of the Velocity Ramping which the Ruida controller has.

Velocity ramping is scheduled to be implemented very soon. To give me an idea of the required granularity, can you tell me what are typical XY accelerations and typical XY movement speeds when the laser is on?

DarkAlchemist

@dc42 said in Velocity Ramping:

@darkalchemist said in Velocity Ramping:

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.

You haven't found it. Click on your user icon, which is at the top right of the top bar if you are viewing this forum on a PC, then select Settings.

Thank you as most forums have it on the post itself so each post can have notifications or you can unclick it to turn it off for that post.

DarkAlchemist

@dc42 said in Velocity Ramping:

@darkalchemist said in Velocity Ramping:

Getting back to the main deal breaker is the lack of the Velocity Ramping which the Ruida controller has.

Velocity ramping is scheduled to be implemented very soon. To give me an idea of the required granularity, can you tell me what are typical XY accelerations and typical XY movement speeds when the laser is on?

There is no typical speed or acceleration but I can tell you the range and that is 0-500mm/s (Chinese type lasers) or up to 1000mm/s on the big boy lasers. Accelerations run from 0-20k where most are 6-12k for the Chinese type laser machines and for the big boys I do not know but think they are the same range.

dc42

Thanks. What I am wondering is at what intervals the PWM needs to be adjusted, given that true continuous adjustment is not practical. With very high accelerations, velocity ramping may not be needed at all, and I doubt that the sort of laser cutter that would be driven by a Duet would reach anything like 1000mm/sec.

If we take a more reasonable figure of 300mm/sec commanded speed and 3000mm/sec^2 acceleration, then full speed will be reached in 100ms. If we change the PWM at 10% intervals, that means we should adjust the PWM at intervals of 10ms or less. Does that sound reasonable?

LightBurn

@dc42 For vector marking, 10% sounds like a reasonable starting point.

It might be worth having a parameter to specify whether to use constant or variable power (GRBL does this), and the higher end DSP controllers let me specify a low and high power value to ramp between, which is handy for CO2 systems where the ionization point gets higher as the tube power goes up.

I chatted with Tony yesterday at MMRF about some ideas I have for dealing with raster data, and he suggested going straight to the source. If you're open to it, I'd love to talk to you about raster data - I have an implementation idea that I believe to be "minimally invasive" for the firmware, but would allow for much less compute overhead. I have a Duet 2 Wifi waiting for me at home and I'd like to look at supporting it in LightBurn soon.

LightBurn

@dc42 - I’ve implemented my raster clustering idea in Smoothieware and can now easily raster 0.1mm pixels at 200mm/sec without hiccups (previous limit was 80mm/sec). I’m going to do some more tests, and make some small changes to the implementation still, but it was simple to add.

DeltaCon

Since I am planning a laser CNC build, I would very much like to hear about any progress concerning the raster capabilities of a duet controller, and the connectivity between Lightburn and Duet. Thanks!

dc42

RepRapFirmware works with LighBurn. Raster clustering has been somewhat delayed because of Duet 3, RepRapFirmware 3 and conditional GCode, but is scheduled for implementation in RRF 3.02.

DeltaCon

Thanks DC42. If I understood correctly from other threads and forums, pixel (say: 0.1mm) needs to be defined in a single gcode line, and that poses a bottleneck on the execution speed. Is that only relevant on quickly moving CO2 machines, or is that also a problem for the usually lower speeds that a diode laser needs? I am going for a diode laser, would a Maestro board suffice for that, like the firmware acts as it is at this moment? Or would it suffice after raster-clustering has been implemented?

DeltaCon

Bump for the previous post (not only intended for David to answer )

And also:

Since my Laser CNC is much simpler that a 3d printer (no heaters, no fans, no multiple extruders or anything) I am thinking about the Duet Maestro. Are there any thinkable reasons to NOT do that and go for a Duet Ethernet? Perhaps in terms of computational power, memory limits that might prevent future firmware updates (sooner that other Gen2 Duets)?