S-curve implementation status?

JuKu

I know I'm asking a question that has been asked many times... But I would so much like to use Duet 3 on my machine: Can you give me any hints on S-curve implementation schedule?

Motivation: My product is not a 3-d printer, but a pick and place machine. S-curve is the only way I know to make a heavy machine to move fast and smooth. There is no such thing as too fast PnP machine, so when pushing to the limits, any mass on the gantry is eventually the limiting factor without S-curve.

OwenD

@JuKu
Can you use input shaping?
Seems to bused on cranes a bit to stop swaying so might also work in your instance too?

https://youtu.be/gzBhTrHv0-c

JuKu

@OwenD Not as it is currently implemented. My customers have a variety of machine implementations, and need a ready to run solution, not something that needs extra time, work, knowledge and equipment to get working.

(I’m about to give up my mostly done Marlin upgrade for the same reason. Marlin does not really allow a setup where some software runs a Marlin board, which is connected to different machines. Marlin wants end users to edit configuration files, recompile and reflash, if their machine is not exactly as the manufacturer supplied. RepRap doesn’t mind, the controller can set it up in startup as it likes.)

dc42

@JuKu we didn't implement S-curve acceleration because it isn't effective at reducing the low frequency resonances that a problematic on 3D printers and similar machines - it can even make them worse, if you increase peak acceleration to maintain the same printing speed. It would be effective at reducing high frequency resonances, but those are not common in the machines we build.

We focussed instead on input shaping, which is very effective at reducing the low frequency resonances.

A further issue is that curves in 3D prints are usually implemented at straight line segments joined together. These can only be printed if instantaneous speed changes ("jerk" in 3D printer speak) is permitted at the angles between segments, or if a complex algorithm is implemented to smooth the corners (so that the print head no longer follows the path commanded by the GCode). This type of jerk (sudden change in velocity) is much worse than the sudden change in acceleration that S-curve acceleration is intended to avoid.

JuKu

@dc42 Fair enough. I totally get the motivation and it makes perfect business sense to focus on your primary target group (3D printers). For a given development effort, you probably sell 100 boards for printers to 1 board for robotics, cnc and other similar stuff. And still I suspect that most of these projects would be happy to spend effort in tuning their machines with accelerometers and such. Still, I was hopeful for 3.5, as I know s-curve is a "one bit" solution in my special case. Maybe I'll look again at input shaping and providing an accelerometer kit with really good instructions to my customers.

dc42

@JuKu what sort of machines do your customers use - in other words, what is your special case?

RRF is used in CNC machines, laser cutters, vertical farming, pick-and-place and other applications as well as in additive manufacturing. I am not aware of S-curve acceleration being important in any of these applications.

In fact, input shaping can be used to approximate S-curve acceleration. Uniquely, RRF provides a custom input shaping mode, which will allow you to create your own custom approximation to an S-curve.

JuKu

@dc42

what sort of machines do your customers use - in other words, what is your special case?

This is a pick and place machine. All I care is to get from one point to another as fast as possible, but smoothly. The catch is (if it is a catch) that the machine sizes vary. For this discussion, the main point is the Y axis. The gantry travels on a moving bar, which can be different length. Also, some customers have done modifications to their machines, and some (not necessarily paying customers) use my software on other machines, not sold by us. I'd like to support them as well. (An anecdote: My best customer, by far, didn't pay for his machine. But he paid back by far more value by improving my open source design.) So, one fixed value determined by us is unlikely enough.

I am not aware of S-curve acceleration being important in any of these applications.

On the other hand, I am very confident that some acceleration management is necessary. It doesn't have to be s-curve, but a constant value is not sufficient. (FYI, this is where I gave up on Duet and decided to wait for 3.5: a thread )

RRF provides a custom input shaping mode...

And apparently, this is where I will look next. As said, I rather use something that doesn't need extra hardware and setup effort. However, I do know I need a better control board. The Duet3, with its software features and powerful drivers is way above anything suitable that I've come across - and the support given on this forum is superb. I'd love to use it.

I know s-curve works (for this application) and would be a simple, cheap and sufficient solution (for this application) . There were some hints that RRF might get it one of these days, perhaps on 3.5, so I asked. Nothing more in it, I'm not arguing it is a necessary function for RFF or better. I also accept (with no hard feelings) that it is not beneficial to your main customer base and you consider input shaping being superior. You can't please everyone, and if this time I "lose", so be it.