Low Speed for 3d Printing application
04 Dec 2019 13:36 #151990
by andypugh
If you could get the slicer to output arcs rather than small line segments then that would help a lot.
(I have checked, and it does not look like Cura can do this. As STL is a polygon mesh this makes some sense, there are no arcs in the input data, so they would have to be created by inference)
Using a coarser STL mesh ought to help. Can you try that and see if it does actually help?
I am not suggesting this as a solution, soley to see if our conjectures seem consistent with reality.
Replied by andypugh on topic Low Speed for 3d Printing application
Ouch, any workaround?
If you could get the slicer to output arcs rather than small line segments then that would help a lot.
(I have checked, and it does not look like Cura can do this. As STL is a polygon mesh this makes some sense, there are no arcs in the input data, so they would have to be created by inference)
Using a coarser STL mesh ought to help. Can you try that and see if it does actually help?
I am not suggesting this as a solution, soley to see if our conjectures seem consistent with reality.
Please Log in or Create an account to join the conversation.
04 Dec 2019 19:15 #152016
by Muz94
I can try, but I'm pretty sure that would help, unless cura breaks straight lines into small segments for no reason.
On the control side do you think that I could do something?
I don't think any slicer on the market at the moment could help with this problem
Replied by Muz94 on topic Low Speed for 3d Printing application
Ouch, any workaround?
If you could get the slicer to output arcs rather than small line segments then that would help a lot.
(I have checked, and it does not look like Cura can do this. As STL is a polygon mesh this makes some sense, there are no arcs in the input data, so they would have to be created by inference)
Using a coarser STL mesh ought to help. Can you try that and see if it does actually help?
I am not suggesting this as a solution, soley to see if our conjectures seem consistent with reality.
I can try, but I'm pretty sure that would help, unless cura breaks straight lines into small segments for no reason.
On the control side do you think that I could do something?
I don't think any slicer on the market at the moment could help with this problem
Please Log in or Create an account to join the conversation.
04 Dec 2019 19:40 #152017
by andypugh
Replied by andypugh on topic Low Speed for 3d Printing application
Some work was done, you could try compiling this experimental branch:
github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db
github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db
The following user(s) said Thank You: Muz94
Please Log in or Create an account to join the conversation.
04 Dec 2019 21:10 - 04 Dec 2019 21:15 #152021
by Muz94
I have a limited experience with github, but i never compiled a huge public project like this.
Do you think that this would solve the issue? I see that it changes the way the speed is calculated, but it looks like nothing has been touched regarding the interpolation / lookahead ecc.
Replied by Muz94 on topic Low Speed for 3d Printing application
This sounds promising, is there any tutorial on how to compile linuxcnc? (especially from a branch).Some work was done, you could try compiling this experimental branch:
github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db
I have a limited experience with github, but i never compiled a huge public project like this.
Do you think that this would solve the issue? I see that it changes the way the speed is calculated, but it looks like nothing has been touched regarding the interpolation / lookahead ecc.
Last edit: 04 Dec 2019 21:15 by Muz94.
Please Log in or Create an account to join the conversation.
05 Dec 2019 00:23 #152030
by Hakan
Replied by Hakan on topic Low Speed for 3d Printing application
If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.
Please Log in or Create an account to join the conversation.
05 Dec 2019 01:25 #152032
by andypugh
A cunning plan. I started thinking down that line, but gave up too early.
An input filter could easily swap U and Z in the code, then swap the wires in the machine.
Replied by andypugh on topic Low Speed for 3d Printing application
If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.
A cunning plan. I started thinking down that line, but gave up too early.
An input filter could easily swap U and Z in the code, then swap the wires in the machine.
Please Log in or Create an account to join the conversation.
05 Dec 2019 06:10 #152046
by Muz94
I mean: this way the tp blends the movements in a XYU space, but the movement actually happens in XYZ, the U value isn't an actual coordinate in the 3d space.
Replied by Muz94 on topic Low Speed for 3d Printing application
Wouldn't this mess up something?
If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.
A cunning plan. I started thinking down that line, but gave up too early.
An input filter could easily swap U and Z in the code, then swap the wires in the machine.
I mean: this way the tp blends the movements in a XYU space, but the movement actually happens in XYZ, the U value isn't an actual coordinate in the 3d space.
Please Log in or Create an account to join the conversation.
05 Dec 2019 09:21 #152052
by Hakan
Replied by Hakan on topic Low Speed for 3d Printing application
I think the tp isn't aware of that. It just looks at speeds, distances and accelerations and tries to find a mathematically good path forward. It is probably best that it uses those values from the involved axis. Maybe it is just to switch the [AXIS_Z] with [AXIS_U] and [JOINT_2] with [JOINT_3] in the ini file. And no need to change hal file or wiring.
Please Log in or Create an account to join the conversation.
05 Dec 2019 12:09 #152059
by andypugh
The TP is blending in XYZ, but Z is now the extruder. So the blending uses the new tp.
Once per layer there will be an old-blended U-axis (Z coordinate) move of the bed, but it doesn't matter if that is slow.
Replied by andypugh on topic Low Speed for 3d Printing application
Wouldn't this mess up something?
I mean: this way the tp blends the movements in a XYU space, but the movement actually happens in XYZ, the U value isn't an actual coordinate in the 3d space.
The TP is blending in XYZ, but Z is now the extruder. So the blending uses the new tp.
Once per layer there will be an old-blended U-axis (Z coordinate) move of the bed, but it doesn't matter if that is slow.
Please Log in or Create an account to join the conversation.
Time to create page: 0.098 seconds