Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. pcsentinel
    3. Posts
    • Profile
    • Following 0
    • Followers 0
    • Topics 36
    • Posts 163
    • Best 2
    • Controversial 0
    • Groups 0

    Posts made by pcsentinel

    • RE: Core XYU Z Movement Issue

      @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.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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!

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU or XYUV

      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?

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      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.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @hackinistrator Same result, no change.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      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.pic1.PNG pic2.PNG

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      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

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

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

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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;

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @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.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      @hackinistrator Because I am using the same logic as worked out in https://forum.duet3d.com/topic/16375/core-xyu-or-xyuv/25?_=1615925048500

      Which means (as far as I understand) you have 4 motors for a core XYU all of which need to move independently to achieve XY or UY movement.

      As I've said above, All X Y U Z movement works absolutely fine when T0 is the active tool, than anomaly only happens when T1 is active.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      The homing move was not called, that just occurs when you do a Z or Y move, that's the whole issue. The tool files are empty.

      If I make Tool 0 o r Tool 2 active (which does not exist I know), then Z and Y moves act as expected. This only occurs when Tool 1 is active

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      Hi DC42, following further tests, it seems to happen with both Y and Z instructions. So with the attached video, The active tool is Tool 1 (U) and I have sent a G1 Z25. The U Carriage moves back to Home and the Z Carriage moves down . If you then send a U-1 from the console. the U moves back to its original location and 1 left.IMG_3633.mp4

      When Tool 0 is active (X) then all works properly.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      Because there is a fault with K5 that is not corrected until V3. I do not really want to go to V3 yet.

      https://forum.duet3d.com/topic/20164/g30-g32-issues-on-duet-wifi-corexyu-with-inductive-probe/7?_=1612371745630

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Core XYU Z Movement Issue

      Duet 2
      Firmware 2.05.1

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • Core XYU Z Movement Issue

      HI, I have just built a Core XYU and basic movement is all working well and as expected. X Homes to left of the gantry and U homes to the right of the gantry.

      I have just started to work towards dual printing, but the issue I have just discovered is that when X is active then Z movement is as you would expect, however when U is active and you try and change Z then the Z Carriage moves as expected but at the same time the U carriage is moved towards its home location.

      Any ideas please?
      TFree,TPost and TPre for both tools are empty.
      config.g

      posted in General Discussion
      pcsentinelundefined
      pcsentinel
    • RE: Independent Z motor levelling issue

      Thanks for your pointers, very useful. Just to update, I have done a number of further experiments and research in the Duet guides. I have decided to come down to the following which seems to exclude unneeded moves

      Adjust Z screw
      ; The adjustment is run 3 times as experiments show slight deviation until 3
      G29 S2 ; clear heightmap
      M561 ; cancel any bed-plane fitting
      G91 ; relative moves
      M98 P"homeall_main.g" ; home XYU
      M98 P"homez_main.g" ; home Z
      G1 H2 Z5 F1800 ; lower Z relative to current position
      G30 P0 X10 Y160 Z-99999 ; probe point near first lead screw
      G30 P1 X300 Y160 Z-99999 S2 ; probe point near second lead screw
      G30 P0 X10 Y160 Z-99999 ; probe point near first lead screw
      G30 P1 X300 Y160 Z-99999 S2 ; probe point near second lead screw
      G30 P0 X10 Y160 Z-99999 ; probe point near first lead screw
      G30 P1 X300 Y160 Z-99999 S2 ; probe point near second lead screw
      G90 ; absolute moves
      M291 P"Heightmap must be regenerated"

      This is just used as a macro and not compensation as the adjustment works as required.

      I understand you only enable heightmap during your prints, but I note from https://duet3d.dozuki.com/Wiki/Using_mesh_bed_compensation:

      "If you home Z using G30 commands in homez.g and homeall.g, you can use G29 S1 in those files, after the G30 command."

      So I will for the moment maintain the adjustment at all times as I have always done previously. But once I am out of the testing phase for this printer I may swap over to your methodology.

      I have bed.g as

      G29 S2 ; clear heightmap
      M561 ; cancel any bed-plane fitting
      G91 ; relative moves
      G1 H2 Z5 F1800 ; lower Z relative to current position
      M98 P"homeall_main.g" ; home XYU
      M98 P"homez_main.g" ; home Z
      G90 ; absolute moves
      M557 X10:300 Y37.5:282.5 P10 ; set matrix
      G29 ; Probe the bed and create heightmap
      G1 X-700 Y700 F10000 ; Move head to home position

      This means I can call it from the the button on the web interface.

      Thanks again.

      posted in General Discussion
      pcsentinelundefined
      pcsentinel