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

kondzio

It appears that the same thing happens when I do a Ditto print. Considering that this happens in both Ditto and Mirror print what could be the problem. I am baffled.

Here is my config: config.g

dc42

Do the arc moves work correctly if you print with just the X tool, or with just the U tool?

kondzio

Ok, I've tested all combinations now.

Printing with X only in either direction (M579 X1 or M579 X-1) works perfectly. Smooth and fast.

Printing with U only in either direction (M579 U1 or M579 U-1) prints slow and it stutters like with a "plain" gcode without arc.

Printing with X and U together either Ditto or Mirror results in an unpredictable movement where on the first G3 move X carriage stops and U carriage advances toward it crashing into it.

Here is my code file: guidefilla-1.gcode

Thanks for looking into it!

kondzio

If I can help with testing or troubleshooting this with you guys, I'd be happy to. I have a dev background and am capable (I'd like to think )

Let me know.

dc42

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

If I can help with testing or troubleshooting this with you guys, I'd be happy to. I have a dev background and am capable (I'd like to think )

Let me know.

I have found a possible problem in the code, but I don't know whether the fix I have applied is correct. Please can you try the firmware at https://www.dropbox.com/sh/bpr6fmuzf8o8cpi/AAAXJMPB36RvXu7z7sgWAAnFa?dl=0 and see if it is any better. This is experimental firmware still undergoing testing, so be ready to turn off the power.

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.