QTPlasmaC with fourth axis - rotary

So, I removed the A axis words and there is no question that it runs way faster with only XYZ. I've played around with the max acceleration/velocity and ,as you have already stated, it doesn't make any difference.
I think you are correct with this being an issue with the planner falling back to a one line lookahead combined with short segments.
The only way I could think of to make this faster would be if the CAM offered a settable parameter for the minimum segment length.

As a crude test I use only the first corner rotation and run it
1. without A axis words
2. as in the code
3. remove every second line so the the segments get longer
4. same as 2 but using G93

I then just look at the YZ plane and the feed rate as indicated in gmoccapy 



It's quite interesting to see the feedrate change during code execution. The corner rotation (A90 to A0) has about twice as many  segments for the first half (A90 to 45) and is a fair bit slower than the second half (A45 to 0)Reducing the segments further  speeds  it up some more  and using G93 does not help at all. 

phillc54 wrote:

This run was with the G93 conversion, apart from a 2.7 second longer run time the numbers are almost identical to the standard G94 run.


EDIT: Changing the A axis to LINEAR made no difference to either the G94 or G93 figures.

I am convinced it is the lack of look ahead in the trajectory planner for axes other than X, Y, or Z.
This seems to gel with 3D printer configs using the Z axis for the extruder and the A axis for the cartesian Z axis.

Something seems wrong with the attachment, there's no G-Code, just a bunch of numbers?

short video here:

github.com/Sigma1912/linuxcnc/assets/460...7d-b2d6-371fb212d876

Aciera wrote:

So, I removed the A axis words and there is no question that it runs way faster with only XYZ. I've played around with the max acceleration/velocity and ,as you have already stated, it doesn't make any difference.
I think you are correct with this being an issue with the planner falling back to a one line lookahead combined with short segments.

Thank you for testing this, I did the same to confirm your findings with similar results. I sure seems to be those combined factors.

The only way I could think of to make this faster would be if the CAM offered a settable parameter for the minimum segment length.

The best option would be to fix the trajectory planner, but that is way above my pay grade.

The best option would be to fix the trajectory planner, but that is way above my pay grade.

+1

The best option would be to fix the trajectory planner, but that is way above my pay grade.

That is not good news at all. How do we get the powers to be to look at this for us? Any suggestions?

This is a known limitation of LinuxCNC it just seems to come up more frequently now with the issue of 3d printing and maybe more frequent use of 4 and 5 axis machining. So this has been discussed for some time.
All I know is hear say and that is that the code for 9 axes blending has been offered to the linuxcnc project but the underlying code has diverged so it cannot simply be merged but would require some work to be integrated.
I'm sure there are a number of users willing to donate money to get path blending expanded, I certainly would if only it helped speed things up

For a bit of fun I did some hacking in the post processor so there were adjustable variables for the axis A angle and the axes X, Y, and Z segment lengths. Even with combinations where the torch height would have been compromised the velocity was way too low.

Attached is a ridiculous sample with no code unless X, Y, or Z move is greater than 5mm or A move is greater 10° or A position is a multiple of 90°. This still didn't make it to half the required velocity.
 

@phil as a sanity check: Are you able to actually have a simulation go at 20'000mm/min?
I just noticed that regardless of  how big the numbers for acceleration and velocitiy I put in the INI file I don't seem to be able to get feed rates above 7896 mm/min on my simulation setup.

[edit]
This is from looking at the feedrate display in gmoccapy, which i presume is correct (I don't actually know where else to look)