Trajectory Planner for 3D printing - A axis blending issues
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 5000
- Thank you received: 1409
14 Jul 2021 16:19 #214760
by Todd Zuercher
Replied by Todd Zuercher on topic Trajectory Planner for 3D printing - A axis blending issues
Like I said I don't know, I really haven't tested beyond 2.7. 2.7 is really very different from the JA versions that came later. In 2.7 and before, the definition of whether an axis (and therefore a joint) was linear or rotary was kind of locked into ABC rotary and all others linear. The developer of the new tool planner was at a loss for how to deal with rotary motion, so he left it out, simply reverting to the old system when ever his was inadequate. That said I believe there are still bugs in the new system that result in unexpected pauses or slowdowns under certain situations.
It is entirely possible that the UVW blending merge got thrown out at some point. I think there may have been a large wreck that resulted in a fairly large code reversion sometime back during the development of 2.8-pre, it is possible that this was some of the code that was pulled out at that time and never found it's way back.
It is also possible that the ties between whether or not an axis is treated as linear or rotary could have loosened with the advent of JA. But I doubt it. But the tie of a particular joint to an axis letter is finally mostly broken so at least a 4th joint can possibly be linear with no rotary hangups.
As far as testing, one thing I used to do when testing XYZW code was to set up identical files one with XYZ and one with XYW. run them and compare the run times. If the XYW code was reverting to the old planner, the run times would usually be longer. Or compare the machine velocity during execution of short line segmented code. For more precise measuring, record Halscope plots of all the axis velocities at points of interest in the code and compare the results. The old planner would limit the maximum velocities during any one g-code line segment to a maximum where all motion could be decelerated to a stop by the end of the next line segment. (only 1 line look ahead) The new planner only limits the velocity to what can be achieved while maintaining the blending tolerances, so there still can be slow downs, they just aren't as large.
It is entirely possible that the UVW blending merge got thrown out at some point. I think there may have been a large wreck that resulted in a fairly large code reversion sometime back during the development of 2.8-pre, it is possible that this was some of the code that was pulled out at that time and never found it's way back.
It is also possible that the ties between whether or not an axis is treated as linear or rotary could have loosened with the advent of JA. But I doubt it. But the tie of a particular joint to an axis letter is finally mostly broken so at least a 4th joint can possibly be linear with no rotary hangups.
As far as testing, one thing I used to do when testing XYZW code was to set up identical files one with XYZ and one with XYW. run them and compare the run times. If the XYW code was reverting to the old planner, the run times would usually be longer. Or compare the machine velocity during execution of short line segmented code. For more precise measuring, record Halscope plots of all the axis velocities at points of interest in the code and compare the results. The old planner would limit the maximum velocities during any one g-code line segment to a maximum where all motion could be decelerated to a stop by the end of the next line segment. (only 1 line look ahead) The new planner only limits the velocity to what can be achieved while maintaining the blending tolerances, so there still can be slow downs, they just aren't as large.
The following user(s) said Thank You: Aciera
Please Log in or Create an account to join the conversation.
14 Jul 2021 16:24 #214761
by Doogie
Ya, I went back and looked at the ngc file and noticed it didn't have the A axis enabled which is strange because I was specifically testing for A axis involvement. I've got a dozen 'test' files and I'm pretty sure once I knew how to "see" the results of the single and 50 word buffer I would have validated the performance was showing the 50 word buffer was being used with A axis involved. I remember pulling the filament from the extruder during testing.
Replied by Doogie on topic Trajectory Planner for 3D printing - A axis blending issues
Hi Doggie,
I saw your video and checked your gcode. In your case ( in the second video) the arc_blend option is working because you didn't have the A axis coordinate inside the gcode. If you execute the same gcode with A axis, I suppose that your second video will be identical to the first one.
Ya, I went back and looked at the ngc file and noticed it didn't have the A axis enabled which is strange because I was specifically testing for A axis involvement. I've got a dozen 'test' files and I'm pretty sure once I knew how to "see" the results of the single and 50 word buffer I would have validated the performance was showing the 50 word buffer was being used with A axis involved. I remember pulling the filament from the extruder during testing.
Please Log in or Create an account to join the conversation.
- AlessandroT
- Offline
- Senior Member
-
Less
More
- Posts: 49
- Thank you received: 4
14 Jul 2021 18:55 #214770
by AlessandroT
Replied by AlessandroT on topic Trajectory Planner for 3D printing - A axis blending issues
I did my homework and I confirm, changing the letter from "A" to "U" in the ini configuration doesn't allow to arc_blend enabling with 4th axis in the 2.9 linuxcnc version.
I'm using the same gcode in two versions: one with the U coordinate and another one, without the U coordinate in each line.
In this way, it's really easy to understand if the blending is working because our setup is really stiff and heavy. In the case of 1 segment of lookahead, you can hear/feel the machine acceleration and decelerations sounds and vibrations, when the blending acts, you can dream better:)
Is it still possible to install-test the Linux 2.8-pre?
I'm using the same gcode in two versions: one with the U coordinate and another one, without the U coordinate in each line.
In this way, it's really easy to understand if the blending is working because our setup is really stiff and heavy. In the case of 1 segment of lookahead, you can hear/feel the machine acceleration and decelerations sounds and vibrations, when the blending acts, you can dream better:)
Is it still possible to install-test the Linux 2.8-pre?
The following user(s) said Thank You: Aciera
Please Log in or Create an account to join the conversation.
15 Jul 2021 10:38 - 15 Jul 2021 10:38 #214834
by Aciera
Replied by Aciera on topic Trajectory Planner for 3D printing - A axis blending issues
Yes, I run current master and I do not see better blending when using U-axis instead of A-axis either.
I don't know if you can go that far back in the development history. But maybe there is some forgotten development branch on the github page.
I don't know if you can go that far back in the development history. But maybe there is some forgotten development branch on the github page.
Last edit: 15 Jul 2021 10:38 by Aciera. Reason: typo
Please Log in or Create an account to join the conversation.
15 Jul 2021 23:56 #214950
by Doogie
Replied by Doogie on topic Trajectory Planner for 3D printing - A axis blending issues
On cartesian FDM printers the Z axis only moves on layer shifts and possibly on retractions but on delta FDM printers X Y and Z are coordinated and part of what makes them so fast.There is a working printer i linked to using axis U (or A ) for Z, and Z axis for driving the extrude.
On FDM printers Z axis moves only on layer shift so not blending or anything required as all other motion is stopped while the Z is moving.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- tommylight
-
- Online
- Moderator
-
Less
More
- Posts: 18563
- Thank you received: 6219
16 Jul 2021 00:58 #214967
by tommylight
Replied by tommylight on topic Trajectory Planner for 3D printing - A axis blending issues
Yes, Deltas are ... interesting with all those moving parts, up/down/sideways/sideways from sideways ....
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
16 Jul 2021 03:07 #214983
by Doogie
Replied by Doogie on topic Trajectory Planner for 3D printing - A axis blending issues
yup and with far fewer parts than a Cartesian and those parts are in triplicate so easier to assemble. My first experience with 3D printing AND LinuxCNC was with Mini Kossel deltas. Well, the early fork of LinuxCNC called Machinekit on a Beaglebone Black. ~2014
Please Log in or Create an account to join the conversation.
- AlessandroT
- Offline
- Senior Member
-
Less
More
- Posts: 49
- Thank you received: 4
16 Jul 2021 09:36 #215008
by AlessandroT
Replied by AlessandroT on topic Trajectory Planner for 3D printing - A axis blending issues
A little update,
I installed and tried the uvw-blending-dev of 2015 github.com/LinuxCNC/linuxcnc/tree/feature/uvw-blending-dev. It's not the latest version, but it's the first one that I was able to install.
With this version, the blending with 4-axis is improved against the 1 segment lookahead, but the motion is not smooth as the lookahead with only 3-axis XYZ.
I wonder if it's possible and how difficult is to hack the tp telling him to blend also if the 4th axis is inside the gcode.
I installed and tried the uvw-blending-dev of 2015 github.com/LinuxCNC/linuxcnc/tree/feature/uvw-blending-dev. It's not the latest version, but it's the first one that I was able to install.
With this version, the blending with 4-axis is improved against the 1 segment lookahead, but the motion is not smooth as the lookahead with only 3-axis XYZ.
I wonder if it's possible and how difficult is to hack the tp telling him to blend also if the 4th axis is inside the gcode.
Please Log in or Create an account to join the conversation.
Time to create page: 0.102 seconds