SplineTravel
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
SplineTravel
Hi!
I'm currently busy on a project I called SplineTravel. The purpose is to use to use cubic Beziers to smooth out toolhead motion when it is to travel without extruding (or cutting). That is, instead of abruptly changing direction and traveling to the next location in straight line, do that in a curve so that the head doesn't have to make a full deceleration-acceleration.
This is probably irrelevant for cutting cncs, where cutting moves are relatively slow. But for 3d-printers, I think this might be interesting. It can potentially avoid blobs, reduce printing shake, reduce drive mechanism wear, reduce noise, and even speed up the long moves (short moves will probably take longer). And I expect it to look cool.
I am doing it as a fully separate g-code filter, in VB6, and it takes me too long to implement all the G-code juggling stuff. So I've briefly looked over what path module can do, and it looks like a good ecosystem for the filter. Hmm.. why didn't I look here before? now I'm close to completing my standalone code... and I'm in doubt f whether to finish up my standalone project, or jump in right now.
Basically, what the filter needs to do, is:
1 read and parse slicer output (G-code)
2 find all travel moves. Also absorb retractions/unretractions and Z-hops.
3 for each travel move, calculate speed before travel, after travel, and generate a Bezier curve motion that does not exceed the acceleration the user can specify. Also, care needs to be taken to not exceed the maximum allowed speed.
4 inject retraction/unretraction into the Bezier moves (tricky)
5 replace the stuff from 2 with the new move
6 write out the resulting G-code
Additional stuff that I'm going to take care of later, when I get something useful:
* take care not to exceed printer size
* optionally create splinetravels for extrusion path corners, to completely kill vibration
* optionally suppress splinetravels in places where it will cause serious stringing or surface defects (I expect these can be even worse than blobs).
I'm currently busy on a project I called SplineTravel. The purpose is to use to use cubic Beziers to smooth out toolhead motion when it is to travel without extruding (or cutting). That is, instead of abruptly changing direction and traveling to the next location in straight line, do that in a curve so that the head doesn't have to make a full deceleration-acceleration.
This is probably irrelevant for cutting cncs, where cutting moves are relatively slow. But for 3d-printers, I think this might be interesting. It can potentially avoid blobs, reduce printing shake, reduce drive mechanism wear, reduce noise, and even speed up the long moves (short moves will probably take longer). And I expect it to look cool.
I am doing it as a fully separate g-code filter, in VB6, and it takes me too long to implement all the G-code juggling stuff. So I've briefly looked over what path module can do, and it looks like a good ecosystem for the filter. Hmm.. why didn't I look here before? now I'm close to completing my standalone code... and I'm in doubt f whether to finish up my standalone project, or jump in right now.
Basically, what the filter needs to do, is:
1 read and parse slicer output (G-code)
2 find all travel moves. Also absorb retractions/unretractions and Z-hops.
3 for each travel move, calculate speed before travel, after travel, and generate a Bezier curve motion that does not exceed the acceleration the user can specify. Also, care needs to be taken to not exceed the maximum allowed speed.
4 inject retraction/unretraction into the Bezier moves (tricky)
5 replace the stuff from 2 with the new move
6 write out the resulting G-code
Additional stuff that I'm going to take care of later, when I get something useful:
* take care not to exceed printer size
* optionally create splinetravels for extrusion path corners, to completely kill vibration
* optionally suppress splinetravels in places where it will cause serious stringing or surface defects (I expect these can be even worse than blobs).
Re: SplineTravel
Why use splines where plain circle-arcs are good enough?
There's really a problem with breaking curved to line-segments (as done with pycam). My CNC router really sounds different when it's handling a real circle (G2/G3) vs handling a circle broken to short linear segments.
If you look at linuxcnc, in some cases it may "round corners". Read more here:
http://wiki.linuxcnc.org/cgi-bin/wiki.p ... oryControl.
You should not use VB in FreeCAD. Python is a nice language once you get used to it, and with Python you have access to all of FreeCAD's internals.
-- Itai
There's really a problem with breaking curved to line-segments (as done with pycam). My CNC router really sounds different when it's handling a real circle (G2/G3) vs handling a circle broken to short linear segments.
If you look at linuxcnc, in some cases it may "round corners". Read more here:
http://wiki.linuxcnc.org/cgi-bin/wiki.p ... oryControl.
You should not use VB in FreeCAD. Python is a nice language once you get used to it, and with Python you have access to all of FreeCAD's internals.
-- Itai
Re: SplineTravel
This might be cool... and indeed nice to integrate to the Path module. There are several ways where this could take place, actually. The Path module basically outputs gcode. So you could have your filter work like a post-processing job, same as the export scripts that transform the GCode output of FreeCAD into a machine-specific dialect.
Another approach could be a new Path feature that takes another Path feature as input, and applies this filter to it.
If we do that, and you use splines, the view provider of the Path module needs to be extended as to display splines, which it doesn't do at the moment.
Another approach could be a new Path feature that takes another Path feature as input, and applies this filter to it.
If we do that, and you use splines, the view provider of the Path module needs to be extended as to display splines, which it doesn't do at the moment.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SplineTravel
circles only make sense when moving with constant speed. I want to accelerate to the full travel speed. And fitting arcs is a problem that I don't have a solution now. Fitting a Bezier is quite simple. Furthermore, I need to inject retraction and z-hopping into the first and the last pieces of the move, so I will have to break up the path into segments anyway (not necessarily lines, but anyway...).nahshon wrote:Why use splines where plain circle-arcs are good enough?
I doubt this is of any use for cnc cutting machines, because of the speeds involved, and because it can't move wherever it likes; 3d printer can.nahshon wrote:My CNC router
this is quite obviousnahshon wrote:You should not use VB in FreeCAD
I'm quite sure my printer doesn't support spline g-move commands, so I will have to split the spline into line segments anyway. So the lack of spline viewprovider is probably not a problem.yorik wrote:view provider of the Path module needs to be extended as to display splines
Re: SplineTravel
Yes I think I recall Dan or Brad also told me that splines are almost never supported by routers...DeepSOIC wrote:I'm quite sure my printer doesn't support spline g-move commands, so I will have to split the spline into line segments anyway. So the lack of spline viewprovider is probably not a problem.
Still, it might be handy to support it, so we can store splines as splines inside FreeCAD, and only discretize at export.
Re: SplineTravel
In case it's of any help the class GeomBSplineCurve offers the method toBiArcs which returns a list of arcs to approximate a b-spline curve.And fitting arcs is a problem that I don't have a solution now.
Re: SplineTravel
True, when doing any NC operation you really want to maintain a constant speed as much as possible! This is true for milling, for laser or plasma cutting and also for 3d printers.DeepSOIC wrote:circles only make sense when moving with constant speed. I want to accelerate to the full travel speed. And fitting arcs is a problem that I don't have a solution now. Fitting a Bezier is quite simple. Furthermore, I need to inject retraction and z-hopping into the first and the last pieces of the move, so I will have to break up the path into segments anyway (not necessarily lines, but anyway...).nahshon wrote:Why use splines where plain circle-arcs are good enough?
Use the maximum speed only for jogging (and then use a straight line whenever possible).
You should be able to approximate any curve with circular arcs, and that would be much better than approximating with straight segments.
I'm not sure if circle arcs (G2, G3) are supported by all 3D printers. Repetier firmware has arcs as an option. IMHO slicers never produce G-code for arcs.
-- Itai
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SplineTravel
Hey! I have first results
Re: SplineTravel
So nice !
This really reminds me those beautiful Volumill paths ! https://www.google.it/search?q=volumill ... 83&bih=719
This really reminds me those beautiful Volumill paths ! https://www.google.it/search?q=volumill ... 83&bih=719
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: SplineTravel
OK, the spline generator is working perfectly (except it is a bit slow, VB6's classes are a problem).
I have a bit of a problem that I can't change feedrate in real time without causing speed mismatch (repetier-host seems to be smart enough to not affect travel moves, which was fine when the moves were straight lines...). But it's not a big problem, this doesn't add too much shake (speed changes involved are rather small compared to what it was when moving in straight line)
Still not ready for real printing, though, but it's coming... In VB now.
I have a bit of a problem that I can't change feedrate in real time without causing speed mismatch (repetier-host seems to be smart enough to not affect travel moves, which was fine when the moves were straight lines...). But it's not a big problem, this doesn't add too much shake (speed changes involved are rather small compared to what it was when moving in straight line)
Still not ready for real printing, though, but it's coming... In VB now.