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

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

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

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

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

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

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

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?