Trajectory Planner for 3D printing - A axis blending issues

I thought I tested this and figured out it was not the case that the A axis dropped the TP to a 1 word buffer here(videos showing 1 word and 50 word buffers): forum.linuxcnc.org/38-general-linuxcnc-q...3-3d-printing#210835

Maybe arc_blend is quite different from what you are saying and seeing?

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.

@Todd, thanks, I can understand the feeling and the scares to upgrade when the stuff are going well. Honestly, I didn't test to swap A axis with U, I only read that it didn't work in some posts. I will do my homework soon. I have some little hope because we are testing the linuxcnc 2.9, and maybe the U swapped tester was using the 2.7!

About the post process inside linuxcnc, I never used this workaround and I will investigate it, but as we are loading very large files and it takes a long time already to be charged, I suppose that this will require even more time. 

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.