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.

AlessandroT wrote:

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.
 

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?

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.

tommylight wrote:

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.

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.

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

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.