Velocity Ramping

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