IDEX printing U-axis incompatible with G2/G3 arc moves

kondzio

This post is deleted!

kondzio

@dc42 Ok, I was able to test the firmware you shared with me. Partial success...

What appears to be working correctly now...

Carriages no longer crash to each other when X and U are printing together either Ditto or Mirror.
X-axis still prints G2/G3 moves as expected "honoring" arc moves, printing smooth and fast.

However, the following issues still persist...

U-axis does not print G2/G3 arcs. It prints like standard G0/G1 moves (stutters and slow).
X and U printing together in Ditto same as above (stutters and slow).
X and U printing together in Mirror mode same as above (stutters and slow).

dc42

@kondzio , thanks for the feedback. Can you post a video showing the movement? Ditto mode would be best so that I can compare the axes.

kondzio

@dc42 In Ditto mode both axis print with stutter.

Another way to put it, only X axis printing alone prints arcs smoothly. Whenever U axis is part of movement the arcs are not smooth at all.

I uploaded 4 files for you. Three short video clips to see the printing, and one picture to compare quality of the printed parts.
I tried to make the stutter visible on the video (maybe hard to notice) but definitely notice the speed difference between X-axis print and the the other two examples. All printed with exactly the same code source file.

[link removed]

dc42

Thanks, U axis printing alone is probably the most important then, and X axis alone may be a useful comparison.

I'm sorry I haven't been able to include a complete fix in release 3.2.2.

kondzio

@dc42 said in IDEX printing U-axis incompatible with G2/G3 arc moves:

Thanks, U axis printing alone is probably the most important then, and X axis alone may be a useful comparison.

I'm sorry I haven't been able to include a complete fix in release 3.2.2.

I agree, and no worries! I will be patient

Thanks!

dc42

Thanks for the videos. To be honest, I can't really see any difference between them. The tool paths appear to be correct in all three videos.

I can see that the print speed is slower on the curves than it is on the straight lines between them. The feed rates on the G2/G3 moves in the GCode file you posted are unchanged from the adjacent G1 moves. So then I think RRF must be computation-speed-limited when printing those curves. I will look again at how RRF calculates the segment size when processing G2/G3 moves, and that the efficiency of processing these moves. I will try your GCode on one of my machines

I can't see any reason in the code why printing with U only would be any different from printing with X only. I did see a reason why printing with X+U might be slower. It's because the firmware was doing three sine or cosine calculations per segment instead of two. I have changed the RRF3.3 code to always do just two.

dc42

I've just compared your X and U videos side by side, and I can see that the X one is printing faster. I will look into this. I no longer think the motion is compute-limited.

If you run the original prints without using ArcWelder, do the X-only and U-only prints run at the same speed?

kondzio

@dc42 said in IDEX printing U-axis incompatible with G2/G3 arc moves:

I've just compared your X and U videos side by side, and I can see that the X one is printing faster. I will look into this. I no longer think the motion is compute-limited.

If you run the original prints without using ArcWelder, do the X-only and U-only prints run at the same speed?

Yes, without the ArcWelder both run slow and produce the same lower quality prints. You can see the comparison in the photo I included with the videos.

To say it differently, when ArcWelder converted file is used only the X axis prints with the advantage of the G2/G3 which allows for better speed and quality.

dc42

This line in config.g is the problem:

M566 X1200.00 Y1200.00 Z60.00:60.00 E300.00:300.00 U:1200.00   ; set maximum instantaneous speed changes (mm/min)

It should be:

M566 X1200.00 Y1200.00 Z60.00:60.00 E300.00:300.00 U1200.00   ; set maximum instantaneous speed changes (mm/min)

(removed the colon after U).

kondzio

Damn, a stupid colon made me feel stupid

Thanks @dc42 for your continued attention to this and for working with me on getting it resolved so quickly. You guys are awesome in doing what you do. Keep up the great work, it is much appreciated.

I hope someone can benefit from my oops in the config.

I've re-tested all my print modes with the same file and it all behaves as I would expect now.

dc42

Thanks for confirming.