If I have a desktop 3d printer; and am plotting a curve; lets say 1/4 circle arch with a radius of 5cm over 10 seconds - is it possible to put numbers on the below?
Ranges for smoothness of curve for command pulses from drivers to the stepper motors?
-> Could the driver send 10 pulses to generate 10 straight lines? Obv not a very smooth curve!
-> In some standard-ish setup; what is the likely range of pulses that will be sent?
Under what scenarios do which components become the limiting factor to "more is better"?
-> If I'm running an arduino does code ever get close to using all 16MHZ?
-> If I had a super-computer connected directly to my steppers; then I guess it comes down to what the motor supports; and my required torque (huh; googling!!)
From some reading; the number of steps per motor rotation is relevant; and the supported pulse rate of a motor can range from 1000 to 20 000 (as ... "some" figures).
So; my guess answers would be that a 16MHZ control could be pushed very hard trying to generate 20 000 pulses; but perhaps that is a much higher end type stepper than is used on a desktop-esk 3d printer.
I would be quite interested to hear ballpark figures for how many pulses a not smooth to smooth circle would take.
A slicer generates GCODE, the GCODE interpreter implements circular motion unless the slicer (or some
preprocessor) has decided to convert circles to line segments, which then fixes the best case resolution
prematurely.
Essentially all g-code is straight lines and there is no circular motion only very close approximations.
Most slicers can also be set for resolution aspects so not always premature.
Although there is a "crossover" between the object / image being manipulated and the generation by a slicers core.
As you rightly stated Mark there are different algorithms being used for curvature calculations.
Not all use Beziers or Bressenham' as some also use a "midpoint" calculation or variations thereof.
Then there are the classes
explicit, implicit, and parametric
Much more to a circle than meets the eye and so many options available to programmers to choose from.
Then throw mesh oversampling / under sampling etc into the mix.