Low Speed for 3d Printing application

More
04 Dec 2019 13:36 #151990 by andypugh

Muz94 wrote: 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.

More
04 Dec 2019 19:15 #152016 by Muz94

andypugh wrote:

Muz94 wrote: 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.

More
04 Dec 2019 19:40 #152017 by andypugh
Some work was done, you could try compiling this experimental branch:

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.

More
04 Dec 2019 21:10 - 04 Dec 2019 21:15 #152021 by Muz94

andypugh wrote: Some work was done, you could try compiling this experimental branch:

github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db

This sounds promising, is there any tutorial on how to compile linuxcnc? (especially from a branch).
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.

More
More
05 Dec 2019 00:23 #152030 by Hakan
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.

Please Log in or Create an account to join the conversation.

More
05 Dec 2019 01:25 #152032 by andypugh

Hakan wrote: 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.

More
05 Dec 2019 06:10 #152046 by Muz94

andypugh wrote:

Hakan wrote: 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.

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.

Please Log in or Create an account to join the conversation.

More
05 Dec 2019 09:21 #152052 by Hakan
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.

More
05 Dec 2019 12:09 #152059 by andypugh

Muz94 wrote: 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.103 seconds
Powered by Kunena Forum