Low Speed for 3d Printing application
05 Dec 2019 12:18 #152060
by Muz94
Replied by Muz94 on topic Low Speed for 3d Printing application
What I meant is: the blending creates a path that differs from the gcode (within a tolerance) right?
But if we blend points in a XYU space, when the u movement isn't actually happening, wouldn't this create artifacts or other issues in the printed part?
But if we blend points in a XYU space, when the u movement isn't actually happening, wouldn't this create artifacts or other issues in the printed part?
Please Log in or Create an account to join the conversation.
05 Dec 2019 13:15 #152061
by andypugh
Replied by andypugh on topic Low Speed for 3d Printing application
It might.
You could try running the G-code in a simulator, then doing a global search-and-replace of U for Z (well, I would use U -> & , Z -> U, & ->Z ) and run the code again, see if it gets faster.
You could try running the G-code in a simulator, then doing a global search-and-replace of U for Z (well, I would use U -> & , Z -> U, & ->Z ) and run the code again, see if it gets faster.
The following user(s) said Thank You: Muz94
Please Log in or Create an account to join the conversation.
05 Dec 2019 17:57 #152078
by Muz94
Replied by Muz94 on topic Low Speed for 3d Printing application
Good idea. I will totally try that.
Today i printed a model with a very low polygon count (a low poly pikachu), and it took about 5 - 6 hours, while cura considered that a 4.30 hour print. That's much closer than usual, so it's a matter of segments number.
Today i printed a model with a very low polygon count (a low poly pikachu), and it took about 5 - 6 hours, while cura considered that a 4.30 hour print. That's much closer than usual, so it's a matter of segments number.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 18563
- Thank you received: 6219
05 Dec 2019 18:10 #152079
by tommylight
Replied by tommylight on topic Low Speed for 3d Printing application
As far as i have noticed, none of the software will account for acceleration and deceleration during milling/printing/cutting, they just calculate the feed distance at the given feed rate.
For plasma cutting i give it 20 to 100% more time depending on how complicated the end result is. That is also due to probing time as that increases a lot the overall time it takes to finish a job.
For plasma cutting i give it 20 to 100% more time depending on how complicated the end result is. That is also due to probing time as that increases a lot the overall time it takes to finish a job.
Please Log in or Create an account to join the conversation.
05 Dec 2019 18:33 - 05 Dec 2019 18:33 #152081
by PCW
Replied by PCW on topic Low Speed for 3d Printing application
One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated
I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated
I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.
Last edit: 05 Dec 2019 18:33 by PCW.
Please Log in or Create an account to join the conversation.
05 Dec 2019 18:55 #152084
by Muz94
How would this work? Do you need to make changes in the gcode to have velocity data or it can be done with the information already present in a normal slicer gcode?
Do you have any advice on where to start?
Replied by Muz94 on topic Low Speed for 3d Printing application
One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated
I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.
How would this work? Do you need to make changes in the gcode to have velocity data or it can be done with the information already present in a normal slicer gcode?
Do you have any advice on where to start?
Please Log in or Create an account to join the conversation.
05 Dec 2019 18:56 #152085
by Muz94
Replied by Muz94 on topic Low Speed for 3d Printing application
I used to think that, but i actually saw a few videos of people comparing real printing times with the estimated ones and with the latest version of cura they are pretty close.
Please Log in or Create an account to join the conversation.
05 Dec 2019 19:01 #152086
by Muz94
Replied by Muz94 on topic Low Speed for 3d Printing application
While looking around for an idea i came across to this configuration :
github.com/dabit20/rpi_cnc
and guess what? he runs the machine with swapped A - Z axes.
I'll try to ask him if he did that to fix this exact problem
github.com/dabit20/rpi_cnc
and guess what? he runs the machine with swapped A - Z axes.
I'll try to ask him if he did that to fix this exact problem
Please Log in or Create an account to join the conversation.
05 Dec 2019 19:25 #152088
by PCW
In the very simplest case you would take motion.current-vel, scale it and feed it to the extruder stepgen velocity
Next would be to delay all motion joints with a delay component and feed the non-delayed velocity to the stepgen
Fancier would be to feed the non-delayed velocity to a filter that compensates for the time domain response
of the extruder
Replied by PCW on topic Low Speed for 3d Printing application
One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated
I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.
How would this work? Do you need to make changes in the gcode to have velocity data or it can be done with the information already present in a normal slicer gcode?
Do you have any advice on where to start?
In the very simplest case you would take motion.current-vel, scale it and feed it to the extruder stepgen velocity
Next would be to delay all motion joints with a delay component and feed the non-delayed velocity to the stepgen
Fancier would be to feed the non-delayed velocity to a filter that compensates for the time domain response
of the extruder
Please Log in or Create an account to join the conversation.
05 Dec 2019 19:43 #152090
by andypugh
Replied by andypugh on topic Low Speed for 3d Printing application
Hopefully in the pipeline.
“The good news is, I have a branch that supersedes it, and does a slightly more complex blend (using two tangential arcs), and can also blend in ABC as well.”
“The good news is, I have a branch that supersedes it, and does a slightly more complex blend (using two tangential arcs), and can also blend in ABC as well.”
Please Log in or Create an account to join the conversation.
Time to create page: 0.110 seconds