Core XYU Z Movement Issue
-
@pcsentinel i think you are making a mess .
for dual carriage (coreXY) printer , if you have 2 motors for each carriage , then its XYUV .
if the second carriage connected to a single motor then its XYU .
your matrix defined as XYU , but drive mapping its XYUV .
how is the second carriage actually connected ? -
@hackinistrator Sorry, but I think you are wrong, please see: the link from above. Also the firmware code from the Duet is as follows:
case KinematicsType::coreXYU: // Core XYU is like CoreXY with an additional U axis controlled by the U and V motors inverseMatrix(0, 1) = 1.0; inverseMatrix(1, 0) = 1.0; inverseMatrix(1, 1) = -1.0; inverseMatrix(1, 3) = 1.0; inverseMatrix(1, 4) = -1.0; inverseMatrix(3, 4) = 1.0; inverseMatrix(4, 4) = 0.0; // V can't be commanded directly break; case KinematicsType::coreXYUV: // CoreXYUV is a dual CoreXY setup inverseMatrix(0, 1) = 1.0; inverseMatrix(1, 0) = 1.0; inverseMatrix(1, 1) = -1.0; inverseMatrix(3, 4) = 1.0; inverseMatrix(4, 3) = 1.0; inverseMatrix(4, 4) = -1.0; break;
i.e. a core XYUV effectively has two XY carriages whereas a Core XYU has 2 heads mounted on a single Y carriage.
I am guessing I have 1 setting wrong somewhere that is causing this issue. Do you have a Core XYU machine, if so maybe you could post the config.g so that I can do a comparison.
-
Can you post some pictures of your machine?
-
@pcsentinel please tell hoy many motors connected to your second carriage .
its possible to make coreXYUV with single gantry , if 2 motors control second carriage . -
@hackinistrator There are4 motors controlling the XYU carriage. please see my post above which shows you that the firmware defines that as being core XYU
-
then its core XYUV , your m669 is wrong .
-
@hackinistrator 4 motors:
case KinematicsType::coreXYU:
// Core XYU is like CoreXY with an additional U axis controlled by the U and V motors
inverseMatrix(0, 1) = 1.0;
inverseMatrix(1, 0) = 1.0;
inverseMatrix(1, 1) = -1.0;
inverseMatrix(1, 3) = 1.0;
inverseMatrix(1, 4) = -1.0;
inverseMatrix(3, 4) = 1.0;
inverseMatrix(4, 4) = 0.0; // V can't be commanded directly
break; -
@Rushmere3D Hi, please see the video linked above and below.
-
you defined custom matrix , not just K5 or K8 . your m669 is wrong .
if you have 4 motors for XYUV
matrix should be something like that :M669 X1:1:0:0:0 Y1:-1:0:1:-1 Z0:0:1:0:0 U0:0:0:1:1 V1:-1:0:1:-1
-
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
-
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:1moving 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.
-
-
@hackinistrator Same result, no change.
-
@pcsentinel can you send m669 in console and paste the resuly here?
-
@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 -
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.
-
I don't suppose you'd be willing to update to RRF3?
-
@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!
-
It's not so bad really. Starting with a clean config might not be the worst thing to do in cases like this.
M201 X1000 Y1000 U1000 V1000 Z250 E250,250
I just noticed in your config a small error. You have a
,
that should be a:
. Things like that can sneak in when you're doing a lot of manual edits.If you still have access to DWC. Upload these 3 zip files, one at a time in the system tab. Don't extract them. Reboot after each. Use M115 to verify the firmware has been applied.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.2.2/Duet2and3Firmware-3.2.2.zip
That will get your firmware and DWC up to date.You can see the change logs here:
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.xFor your config, might be a good idea to run through the configurator tool and generate a fresh set for RRF3.
https://configtool.reprapfirmware.org/StartThen you can add back in your additional axis and things.
Backup your existing config files in the sys folder in case you want to switch back to RRF3. IT’s easy to switch back and forth, just upload the zip file for the version you want and then upload your config files.
These documents will come in handy during the conversion.
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview
https://duet3d.dozuki.com/Wiki/GcodeAnd testing your config for errors with M98 P"config.g" is helpful.
-
@pcsentinel said in
Further, When Tool1 is active G1 U commands acts as expected, but G1 X commands move the U carriage and not the X carriage.
i think this is normal , when T1 selected x movement is tied to u .
what strange is u moves when you try to move z .
maybe remove m501 and try .