Curved paths

Hi all,
I've been thinking recently about an improved method of controlling the X/Y motors, based on curves rather than straight lines. My main motivation in this is to get away from the planar-triangle meshes that are the current norm (e.g. STL files), so that the slicer can send a better representation of the model to the printer. (It does seem to be a chicken-and-egg thing... no-one is particularly interested in curved printer paths because slicers only produce straight lines because they start from triangle meshes, but there's no great move away from triangle meshes because printers don't do good curved paths). e.g. Although Marlin processes G-code commands to move along curved paths, it does it by converting the curved path to a series of 1mm segments.

With various alternatives to STL starting to be promoted (mainly for multi-colour, multi-material reasons), I thought this would be a good time to look at improving the printer path for curves.

My thought was that by implementing (e.g.) Bresenham's ellipse-drawing algorithm, the precision of elliptical & circular arc paths could be improved to +/- half a step (or perhaps even +/- half of 1/32 step with the right driver), with resultant improvement in output quality. It may also be that this would improve the speed of the print a little, since speed in each axis could be maintained at maximum levels. e.g. drawing a circle would involve sinusoidally accelerating the X & Y motors between negative and positive maximum speed.

Is anyone working in this space?

Frank

What alternatives to STL representation do you have in mind?

Instead of using Bresenham, which sends stepper motor pulses at irregular intervals, why not calculate the times when the next steps are due based on distance travelled along the curve? I do a similar thing to generate the motor movements on a delta printer without using segmentation, in RepRapFirmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
What alternatives to STL representation do you have in mind?

I'm thinking of AMF, which allows for curved triangles. I've checked a couple of programs (OpenSCAD, OpenJSCAD), and they don't seem to use this feature.

Quote

Instead of using Bresenham, which sends stepper motor pulses at irregular intervals, why not calculate the times when the next steps are due based on distance travelled along the curve? I do a similar thing to generate the motor movements on a delta printer without using segmentation, in RepRapFirmware.

For sure, I haven't thought it all through... I just mentioned Bresenham because it's the only curve-drawing algorithm I'm familiar with. I'm not even sure how I would go about generating the pulses at the right times. Hence asking whether anyone else had worked through this before.
.
Thinking out loud then...

Here's the train of X & Y pulses and X,Y positions for a Bezier curve (50, 50, 75, 100, 100, 100), based on the code at http://members.chello.at/~easyfilter/bresenham.html

x & y are where the algorithm wants to generate x & y pulses.

X	Y	slope	Pulse X	Pulse Y
50	50	1.98	 x	y
51	51	1.94	 	y
51	52	1.94	 x	y
52	53	1.9	 	y
52	54	1.9	 x	y
53	55	1.86	 	y
53	56	1.86	 x	y
54	57	1.82	 	y
54	58	1.82	 x	y
55	59	1.78	 	y
55	60	1.78	 x	y
56	61	1.74	 	y
56	62	1.74	 x	y
57	63	1.7	 x	y
58	64	1.66	 	y
58	65	1.66	 x	y
59	66	1.62	 	y
59	67	1.62	 x	y
60	68	1.58	 x	y
61	69	1.54	 	y
61	70	1.54	 x	y
62	71	1.5	 x	y
63	72	1.46	 	y
63	73	1.46	 x	y
64	74	1.42	 x	y
65	75	1.38	 	y
65	76	1.38	 x	y
66	77	1.34	 x	y
67	78	1.3	 x	y
68	79	1.26	 	y
68	80	1.26	 x	y
69	81	1.22	 x	y
70	82	1.18	 x	y
71	83	1.14	 x	y
72	84	1.1	 x	y
73	85	1.06	 x	y
74	86	1.02	 x	y
75	87	0.98	 x	y
76	88	0.94	 x	y
77	89	0.9	 x	y
78	90	0.86	 x	y
79	91	0.82	 x	y
80	92	0.78	 x	y
81	93	0.74	 x	y
82	94	0.7	 x	y
83	95	0.66	 x	
84	95	0.62	 x	y
85	96	0.58	 x	y
86	97	0.54	 x	
87	97	0.5	 x	y
88	98	0.46	 x	
89	98	0.42	 x	
90	98	0.38	 x	y
91	99	0.34	 x	
92	99	0.3	 x	y
93	100	0.26	 x	
94	100	0.22	 x	
95	100	0.18	 x	
96	100	0.14	 x	
97	100	0.1	 x	
98	100	0.06	 x	
99	100	0.02	 x

Worst case for irregularity in pulses is where the slope is at 1.5 and its inverse 0.66. This is irrespective of scale -- the same stuttering of pulses is apparent in the same region when I scale everything up by a factor of 100. Accelerating the motors just complicates things more! This is caused by the quantization of pulses to integral (x,y) positions by the algorithm.

Instead, I guess the answer is to calculate the slope of the curve at each point, and use that to set the relative frequencies of X & Y pulses at that point. Accelerate (say) the X axis towards MIN(maximum speed, maximum speed/ratio), remembering to decelerate it before the end of the curve. At each pulse of the X axis, calculate the slope of the curve and change the pulse interval of the Y axis to keep the ratio of speeds.

Thoughts anyone?

You don't need to use the slope of the curve. Instead, write down the equations that give the X and Y coordinates as a function of time. There will be separate equations for the acceleration, steady speed, and deceleration phases. Then invert these equations to solve for time in terms of X. Similarly for Y. This gives you the time from the start of the move that each step is due. This is what I do in my precise delta movement code. The equations are quadratic so not difficult to solve.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

In practical terms, what exactly would anyone gain with moving away from STL and any of the standard firmwares? I can print curves just fine on my Prusa i3, including very small radius circles.

Edit: please note the operative word here is practical.

Edited 1 time(s). Last edit at 05/28/2015 07:08AM by AndrewBCN.

Quote
AndrewBCN
In practical terms, what exactly would anyone gain with moving away from STL and any of the standard firmwares? I can print curves just fine on my Prusa i3, including very small radius circles.

For a start, the slicing programs would have a better chance of getting the inner diameter of circular holes right.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
AndrewBCN
In practical terms, what exactly would anyone gain with moving away from STL and any of the standard firmwares? I can print curves just fine on my Prusa i3, including very small radius circles.

For a start, the slicing programs would have a better chance of getting the inner diameter of circular holes right.

@ dc42

Have you ever printed the very same g-code on two different printers and noticed that the inner diameter of circular holes was not the same? I have. Even changing the filament on the very same printer will sometimes result in variations in the inner diameter of circular holes.

"Getting the inner diameter of circular holes right" to use your expression, is more a matter of empirical experimentation and calibration on a particular printer, than the use of pure curved paths vs. approximating straight segments.

Nothing to be gained here by moving away from STL, sorry.

Quote
AndrewBCN

Quote
dc42

Quote
AndrewBCN
In practical terms, what exactly would anyone gain with moving away from STL and any of the standard firmwares? I can print curves just fine on my Prusa i3, including very small radius circles.

For a start, the slicing programs would have a better chance of getting the inner diameter of circular holes right.

@ dc42

Have you ever printed the very same g-code on two different printers and noticed that the inner diameter of circular holes was not the same? I have. Even changing the filament on the very same printer will sometimes result in variations in the inner diameter of circular holes.

"Getting the inner diameter of circular holes right" to use your expression, is more a matter of empirical experimentation and calibration on a particular printer, than the use of pure curved paths vs. approximating straight segments.

Nothing to be gained here by moving away from STL, sorry.

1. It has been pointed out numerous times that when you print a ring, the filament on the inside has less length to fit in, so it has to occupy more width than the slicer allowed for (because the slicer works on straight lines), and this is one of the reasons for the inside being too small. A slicer that knew it was printing a curve could compensate for that.

2. Yes the size of small holes does depend on the printer. If the slicer knew it was processing a curve, and knew the radius, then the slicer could make a correction, controlled by a parameter in the printer and/or filament configuration. Then I would be able to design parts with the correct hole sizes, and print them on any printer, once the slicer has been configured for that printer.

3. I would also much prefer to have OpenScad output a true cylinder when I ask for one, not a polygonal prism which means I have to consider what $fn factor is appropriate.

So IMO there is a lot to be gained by moving away from STL to a format that includes curves.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

There is no such thing as a "true circle" or a "true cylinder" or a "true sphere" in the digital world, we are always dealing with approximations, as you are fully aware of.

The same applies to the quantity of extruded filament that any slicer determines should be used on a straight or approximated curved path, and it would still be a (quite rough) approximation if the slicer algorithm had to deal with a "pure" curved path.

Again, in practical terms there is strictly nothing to be gained, and much to be lost, by moving away from STL and standard firmware that approximates curves using short straight segments. At the end of the day you would have lost an enormous amount of time, energy and possibly money and you would still be dealing with approximations that need empirical corrections/calibration to "get right" (i.e. print to approximately correct dimensions), whether we are dealing with straight, curved, inner or outer paths of a printed object.

As for dealing with setting $fn in OpenSCAD file, you can set the default that you want at the beginning of any source file, it doesn't really require more (or less) than $fn=64; in 99% of all OpenSCAD sources.

Andrew, I don't understand why you are being so negative.

Quote
AndrewBCN
There is no such thing as a "true circle" or a "true cylinder" or a "true sphere" in the digital world, we are always dealing with approximations, as you are fully aware of.

The approximations we have to accept in STL files and in our slicer output are much courser than our printers can handle - and printers are getting better all the time.

Quote
AndrewBCN
Again, in practical terms there is strictly nothing to be gained, and much to be lost, by moving away from STL and standard firmware that approximates curves using short straight segments.

That may be your opinion, but it certainly isn't mine. What do you think there is to be lost? I want a world in which I can download a design from Thingverse and not have to adjust the hole sizes for my printer (which I can't do if all I am given is an STL file anyway). A necessary prerequisite of that is that that slicer knows that it is printing a circle (whether or not the printer knows it). STL files are a hack as far as 3D printing is concerned - just as segmentation to approximate the movement of a delta printer is a hack that is no longer necessary.

Perhaps we will just have to agree to differ.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I see some direct benefits in moving to curves:

1. Better quality of output due to smaller approximations, more accurate placement of the head, no jerking acceleration between segments, more consistent thickness of deposited filament due to more consistent speed of the nozzle.
2. Probably faster printing since higher speeds will be able to be maintained.
3. Maybe also less vibration, consequently better quality and machine life.

There's also the indirect benefit of better models being shared. This is particularly true of shared files on (e.g.) Thingverse, where you're limited to the quality of the STL generated by the originator. (I know this doesn't apply to OpenSCAD source files, but the vast majority of shared files are currently STL).

Whether these benefits are practical depends on how much the end user values quality and print speed and durability

Bear in mind that this is a software change, so it's a one-off development effort that could be retrofitted to all? Cartesian printers.

3D printing is in a development/growth phase which I think is approaching an explosion of use... each improvement that moves it forward will make it a more widely useable, more widely used technology and closer to that consumer-use threshold.

Whilst there is a downside of potentially wasted time, that's the nature of research and development. Worst case, this is consigned to the scrapheap of 3D TVs and Betamax and bubble memory and everyone carries on with the inferior technology.

I agree that 95% of the people are happy with STL files now but if a better format became standard at a reaonable cost they would no longer be happy with the segments that are produced now.
In addition STL has no provision for color so doing dual extrusion for supports or color change is very dificult. I am trying to learn Design Spark Mechanical as it exports to AMF and I believe (hope) slic3r supports it.
I wrote a program to plot Bezier curves but it used constant change in x or y to plot and I agree with dc42 it would need to be done in constant time intervals to have smooth filament flow.
I don't need Bezier curves but I would like to do arcs/circles with one command.
A long time agoI wrote a program to convert text fonts into dfx for milling. I found converting curve to series of arces gave a very good representation of the font without the overhead of using curves.

Thanks George... Just for clarification, I'm not proposing to use Bezier curves. I just happened to use that example because it conveniently went from one curve endpoint to the other, unlike Bresenham and similar which work in one octant and then mirror that to generate the entire shape. With Bresenham it is therefore inconvenient to draw an arc which crosses an octant boundary (e.g. an arc from 20 degrees to 60 degrees).I'm still reflecting on the maths, but it may be that the pulse timings for a circular arc are easier to calculate than for Bezier curves.

So long as STL is in place, there's virtually no benefit for a Cartesian printer to be able to follow a curved path. But, as you say, with the increasing number of multi-colour/multi-material printers, the life of STL is limited. Since AMF seems to be a contender as a replacement for STL, and AMF supports curved triangles, it seemed to me to be an opportune time to start thinking about curved printer paths. I think it's implicit in AMF that the edges of its curved triangles represent circular arcs. If the centres of the three circles for the edges are coincident, then I think that all sections through the curved triangle will be circular arcs. But, if centres aren't coincident, I suspect (i.e. my 3D geometry isn't good enough to be sure) that an arbitrary section through the curved triangles need not be a *circular* arc. I'm not sure whether it must be elliptical, or whether some other arbitrary curve could result.

According to http://reprap.org/wiki/G-code#G2_.26_G3:_Controlled_Arc_Move says that a number of firmwares (Sprinter, Repetier, Smoothie, grbl) support the G2/G3 curved path commands, and Marlin does only for SCARA printers. These commands are for circular arcs only.

Quote
frankvdh
I see some direct benefits in moving to curves:

1. Better quality of output due to smaller approximations, more accurate placement of the head, no jerking acceleration between segments, more consistent thickness of deposited filament due to more consistent speed of the nozzle.
2. Probably faster printing since higher speeds will be able to be maintained.
3. Maybe also less vibration, consequently better quality and machine life.

LOL!
You are trying to make this into a panacea for all printing woes, which is quite absurd, since there is no direct causal link between the file format being able to convey circular paths, and any of the things you have listed above!

Quote
frankvdh
There's also the indirect benefit of better models being shared. This is particularly true of shared files on (e.g.) Thingverse, where you're limited to the quality of the STL generated by the originator. (I know this doesn't apply to OpenSCAD source files, but the vast majority of shared files are currently STL).

Whether these benefits are practical depends on how much the end user values quality and print speed and durability

Bear in mind that this is a software change, so it's a one-off development effort that could be retrofitted to all? Cartesian printers.

Nope, this is a file format change, and it affects the entire software toolchain. All that for zero practical benefits, despite your wishful thinking that it would.

Quote
frankvdh
3D printing is in a development/growth phase which I think is approaching an explosion of use... each improvement that moves it forward will make it a more widely useable, more widely used technology and closer to that consumer-use threshold.

Whilst there is a downside of potentially wasted time, that's the nature of research and development. Worst case, this is consigned to the scrapheap of 3D TVs and Betamax and bubble memory and everyone carries on with the inferior technology.

I agree that 3D FDM printing technology is still evolving, I just don't think you have established any logical/causal link between an intermediate file format supporting circular paths and any practical improvement in print quality (and much less print speed, lower vibrations, etc... as you listed above).

Edited 2 time(s). Last edit at 05/28/2015 06:00PM by AndrewBCN.

Quote
AndrewBCN

Quote
frankvdh
I see some direct benefits in moving to curves:

1. Better quality of output due to smaller approximations, more accurate placement of the head, no jerking acceleration between segments, more consistent thickness of deposited filament due to more consistent speed of the nozzle.
2. Probably faster printing since higher speeds will be able to be maintained.
3. Maybe also less vibration, consequently better quality and machine life.

LOL!
You are trying to make this into a panacea for all printing woes, which is quite absurd, since there is no direct causal link between the file format being able to convey circular paths, and any of the things you have listed above!

Thank you for telling me what I am trying to do.Your ESP ability is exceeded only by your rudeness.

1. AMF: The curvature information has been shown to reduce the error of a spherical surface by a factor of 1000 as compared to a surface described by the same number of planar triangles.
2 & 3: From my point of view, a printer moving in near-circular (within the limitations of a stepper motor's step size) arcs would be able to change direction more smoothly than one that was constrained to straight lines, resulting in less acceleration/deceleration, and consequently higher speeds and less vibration.

The ability of the printer to move in these smooth arcs is dependent on the slicer providing these smooth paths, which in turn is dependent on the file format. QED

I, and I'm sure all those without your extraordinary powers, would now appreciate you sharing the reasoning behind your assertion.

Quote
dc42
Andrew, I don't understand why you are being so negative.

Quote
AndrewBCN
There is no such thing as a "true circle" or a "true cylinder" or a "true sphere" in the digital world, we are always dealing with approximations, as you are fully aware of.

The approximations we have to accept in STL files and in our slicer output are much courser than our printers can handle - and printers are getting better all the time.

...

Yes, printers are getting better all the time, and technology is still evolving. But some down-to-earth reasoning does not hurt either, and that is not the same as being negative.

So, right now I generally use 0.2mm layers with a 0.3mm or 0.4mm nozzle, and these basically define the practical (as in, not theoretical) resolution that I can achieve with my 3D printers. Now please explain/demonstrate how switching to a different intermediate file format than STL - for example, AMF, which does support curved triangles - would improve the quality of my prints (assuming the rest of the toolchain knows how to deal with AMF files and curved paths).

Quote
frankvdh
Thank you for telling me what I am trying to do.Your ESP ability is exceeded only by your rudeness.
...

Thank you for making this into an ad hominem argument, it allows me to disregard any of your further arguments, however logical or illogical they may be...

I most often disagree with dc42 but not once have any of our arguments descended into ad hominem attacks, so I have come to respect him for that regardless of our differences in opinion.

Oh, do me a favour... Now you're saying that *this* isn't ad hominem:

Quote

LOL!
You are trying to make this into a panacea for all printing woes, which is quite absurd,

And this is a copout:

Quote

Thank you for making this into an ad hominem argument, it allows me to disregard any of your further arguments

I conclude that you don't actually have any basis for your assertions (given the lack of any supporting evidence, they don't even qualify as arguments). Consequently, whether you disregard my comments or not is irrelevant.