QTPlasmaC with fourth axis - rotary
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.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
- snowgoer540
- Offline
- Moderator
- Posts: 2388
- Thank you received: 779
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?
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Thank you for testing this, I did the same to confirm your findings with similar results. I sure seems to be those combined factors.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 best option would be to fix the trajectory planner, but that is way above my pay grade.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.
Please Log in or Create an account to join the conversation.
+1The best option would be to fix the trajectory planner, but that is way above my pay grade.
Please Log in or Create an account to join the conversation.
That is not good news at all. How do we get the powers to be to look at this for us? Any suggestions?The best option would be to fix the trajectory planner, but that is way above my pay grade.
Regards
Marius
www.bluearccnc.com
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
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.
Attachments:
Please Log in or Create an account to join the conversation.
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)
Please Log in or Create an account to join the conversation.