Done, I know its taken a while, https://www.thingiverse.com/thing:2388496 including a link to a youtube video.

Hi Veti, thanks I was actually writing a response when yours came through. It was my lack of understanding. I was using the S2 or H2 command to ignore endstops as I am just commissioning at this stage so don't have any fitted yet. So when you enter G1 X10 S2 when the head is at 0,0,0 then I was expecting a positive X movement only. when I set M564 H0 instead then G1 X10 does exactly what it should. My bad!

@dc42 Hi dc, just thought I would add a prompt to my final comment in this thread, it may be worth a quick look and add it to the bug list.

@Phaedrux Hi Phaedrux, well I but the bullet and upgraded, it wasn't as bad as I had anticipated. Thanks for the kick up the butt!

I used K5 rather than a full matrix layout as that should be fixed in 3.2.2

Unfortunately it didn't stop the issue from occurring. However as I had spent so long looking at the config, something popped out, The Tool 1 definition includes the X3 command so that X moves are translated to U moves when a normal gcode file is processed. And this points to my other observation above that X moves with Tool1 selected move U and not X. So I thought I would experiment, if you remove the X3 from the line then the issue does not occur, i.e. with tool 1 active Z and Y moves operate exactly as expected.

But of course you cant leave it like that otherwise printing wouldn't work. So I thought well, lets just run a test print with Tool 1 as the active extruder. Guess what Z moves when printing do not cause the U carriage to move home.

So it appears that this issue is only present when not printing and probably (?) only occurs with a CoreXYU configuration. It just makes things hard to tune. And also made me waste peoples time with this non-ish issue.

Note, I have yet to do a full 2 extruder print, but I have more confidence that it will work now.

@Phaedrux Hi, I didn't want to, but I am now thinking it may be inevitable, if only to eliminate V2 as a source of the issue.

Just dreading having to go through the conversion process!

Hi curlypaul, I hope you are still connected, I am experiencing similar problems with my Core XYU.
https://forum.duet3d.com/topic/22176/core-xyu-z-movement-issue/11?_=1615984614686.

If you are still out there could you send over a copy of your final config.g please?

Further observations.

Following a reboot, with tool 0 active all movement is as expected.
Issue a T1, to make Tool 1 active, issue a G1 Z5, Z moves down and U stays where it is.
Issue a T0 all movement as expected.
Issue a T1 (for the second time) the issue occurs whereby at the same time as the Z movement is taking place, U returns to the home position.

Further, When Tool1 is active G1 U commands acts as expected, but G1 X commands move the U carriage and not the X carriage.

@hackinistrator
Kinematics is modified Cartesian, matrix:
1.00 1.00 0 0 0
1.00 -1.00 0 1.00 -1.00
0 0 1.00 0 0
0 0 0 1.00 1.00

@hackinistrator Same result, no change.

Well, I am now even more confused, I have tried various options including changing the matrix to
M669 X1:1:0:0:0 Y1: -1:0:1:-1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:1

moving M584 to above M669

But I have now discovered that the issue is intermittent, so when Tool 0 is active then everything always works fine, but when Tool 1 is active, sometimes a G1 Z5 will move the U carriage to its home position (without being told to) whilst at the same time Z moves as instructed, other times just the Z carriage moves as expected.

And its not after a config change. Sometimes its as if some internal variable is set or cleared. So everything works, and then you give an instruction and following that the aberration occurs again.

The other thing I have noticed is in the pics, If X is homed to -94 (pic1) and then I make Tool 1 active the X location is shown as the U location in the interface.

I will look at the matrix, but I am failing to understand the relationship to the actual issue, which is that when Tool 0 is active then everything works fine, but when Tool 1 is active then the U is parked for any Y or Z moves.

To prove it, here is a video taken with Tool 0 active.x1.mp4

@Rushmere3D Hi, please see the video linked above and below.