Printhead jerks when moving.
-
@dc42
Or do I have to consider something else when I use the G1 H2 command? -
@tkln I don't know if this will help, but I think it may be related to how the axes are paired. You have
M584 X0.4 Y0.5 Z0.0 U0.1 V0.2 W0.3 P6
and
M584 X0.4:0.5 Y0.2:0.3 Z0.0:0.1 E1.0
When you change to 6 axes, the Y axis changes from driver 0.5 to driver 0.2 and 0.3. The other axes are similar: X adds on the Y driver 0.5 (rather than U) and Z adds the U driver. This seems strange to me, and may be causing the firmware issues. You should try defining the axes in pairs such that X:U, Y:V and Z:W. Then when you change to 6 axes, X, Y and Z stay as X, Y and Z. I'd also define all axes in config.g, and then you only have to reconfigure X, Y and Z when you change. eg, in config.g try:
M584 X0.4:0.1 Y0.5:0.2 Z0.0:0.3 U0.1 V0.2 W0.3 E1.0 P3 ; Motoren entkoppeln M350 X16 U16 Y16 V16 Z16 W16 E16 I1 ; configure microstepping with interpolation (*) M92 X160.00 U160.00 Y160.00 V160.00 Z160.00 W160.00 E690.00 ; set steps per mm (*) M566 X1200.00 U1200.00 Y1200.00 V1200.00 Z1200.00 W1200.00 E300.00 ; set maximum instantaneous speed changes (mm/min) (*) M203 X18000.00 U18000.00 Y18000.00 V18000.00 Z18000.00 W18000.00 E7200.00 ; set maximum speeds (mm/min) (*) M201 X1000.00 U1000.00 Y1000.00 V1000.00 Z1000.00 W1000.00 E3000.00 ; set accelerations (mm/s^2) (*) M906 X1600 U1600 Y1600 V1600 Z1600 W1600 E1200 I80 ; current (A)
Then to swap to 6 axes, just send
M584 X0.4 Y0.5 Z0.0 P6
To swap back, send:
M584 X0.4:0.1 Y0.5:0.2 Z0.0:0.3 P3
This will change which axis moves the effector in which direction, but I think this should be more consistent for the firmware. I'm not entirely sure what this will do to homing; eg if you home X, Y and Z as normal in 3 axis mode, whether U, V and W are marked as homed as well, and what happens when you change over, ie if they all become unhomed (I don't think they will).
Ian
-
@droftarts
Thanks for your answer but unfortunately that didn't work either.
My gcode looks like this:
Do I have to add something else so that the movement is not so jerkyG1 X11.7164 Y12.161 Z0.26626 U0.26626 V-9.91903 W-10.3636 E1.6307 F3000 H2 G1 X6.65954 Y6.65946 Z-12.2144 U-12.2144 V6.65778 W6.65786 E0.8963 F3000 H2 G1 X-11.5935 Y-11.5935 Z-0.579091 U-0.579091 V10.2774 W10.2774 E0.1618 F3000 H2 G1 X-6.76609 Y-6.76601 Z12.2234 U12.2234 V-6.56607 W-6.56615 E0.8963 F3000 H2 G1 X0.402068 Y0.402067 Z-0.17198 U-0.17198 V-0.0989229 W-0.0989218 E0.0 F3000 H2 G1 X-0.027972 Y-0.0279724 Z-0.070774 U-0.070774 V0.0934805 W0.093481 E0.0126 F3000 H2 G1 X0.0696473 Y0.0696465 Z-0.111242 U-0.111242 V0.0675966 W0.0675973 E0.0152 F3000 H2
-
I have now also tested moving the motors in the coupled state with the G1 H2 command and the movement is just as jerky as when it is uncoupled.
.... G1 X0.0583302 Y0.0583302 Z-0.0881923 E0.0135 F500.0 H2 G1 X0.112918 Y0.112918 Z-0.171268 E0.0263 F500.0 H2 G1 X0.00815441 Y0.00815441 Z-0.0123959 E0.0019 F500.0 H2 G1 X-0.580933 Y-0.580933 Z0.353199 E0.0769 F500.0 H2 G1 X-0.155603 Y-0.155603 Z-0.000999434 E0.0244 F500.0 H2 G1 X-0.110898 Y-0.110898 Z-0.000845101 E0.0173 F500.0 H2 ...
Config.file:
M584 X0.4:0.5 Y0.2:0.3 Z0.0:0.1 U0.1 V0.2 W0.3 E1.0 P3 M350 X16 U16 Y16 V16 Z16 W16 E16 I1 ; configure microstepping with interpolation (*) M92 X160.00 U160.00 Y160.00 V160.00 Z160.00 W160.00 E690.00 ; set steps per mm (*) M566 X5000.00 U5000.00 Y5000.00 V5000.00 Z5000.00 W5000.00 E300.00 ; set maximum instantaneous speed changes (mm/min) (*) M203 X8000.00 U8000.00 Y8000.00 V8000.00 Z8000.00 W8000.00 E7200.00 ; set maximum speeds (mm/min) (*) M201 X2000.00 U2000.00 Y2000.00 V2000.00 Z2000.00 W2000.00 E3000.00 ; set accelerations (mm/s^2) (*) M906 X1800 U1800 Y1800 V1800 Z1800 W1800 E1100 I80 ; set motor currents (mA) and motor idle factor in per cent (*) M84 S30
-
@tkln I think maybe an H2 move is seen as a complete move, and motion stops after each H2 move. @dc42 will need to confirm this. I'm not sure what the workaround would be.
Is there any particular reason to use an H2 move rather than a normal move, without any H parameter? You have split the axes already, so they should move independently when you want them to.
Ian
-
@droftarts Unfortunately that does not work. When I use H2, the correct movement is performed, but when I don't use H2, the system moves incorrectly.
Or if I omit the H2 do I need to add something else?When I enter this, the effector moves -140 mm along the y-axis:
G91 G1 X14.7126 Y14.7126 Z-51.0191 U-51.0191 V14.7126 W14.7126 E0 F1000 H2 ; move y -140 mm
With the command, the effector moves in the y and z directions:
G91 G1 X14.7126 Y14.7126 Z-51.0191 U-51.0191 V14.7126 W14.7126 E0 F1000
Without the H2 command, the Z0.0 and U0.1 axes do not move
-
@tkln thats probably the difference in the way H2 works.
e.g. with a delta at 0,0,0 coordinates, G1 Y10 would move the effector to Y10 on the same plane. G1 Y10 H2 would move the Y tower by 10mm
So by extension, when at 0,0,0 coordinates, G1 Y10 Z10 would move the effector up 10mm and to X0 Y10, where as G1 H2 Y10 Z10 would move the towers up by 10mmin your example you're trying to move to Z-51 which will be outside the axis maxima and minima (its typically Z-1 on a delta)
-
@tkln As @jay_s_uk says, when using H2 you're not moving as a delta any more. Without H2, it reverts to delta motion on X, Y and Z. I think you're going to need to modify the firmware to either allow H2 moves to be added to the motion planning queue (so it doesn't come to a stop after each one - at least I think that's what's happening), or amend the kinematics to control the axes correctly (trickier).
Ian
-
-
@droftarts @jay_s_uk Can I free the extruder command E from the H2 command and run it normally?
G1 X14.7126 Y14.7126 Z-51.0191 U-51.0191 V14.7126 W14.7126 E0.594 F1000 H2```
-
@tkln No, I don't think you can remove the E axis from the H2 and still have coordinated motion.
However, I did have another idea. If you aren't using delta kinematics when using all 6 axes, because you are solving for the delta movement beforehand in the Gcode (which is the reason you use G1 H2 moves), there's no real reason to run the 6 axes with delta kinematics. In which case, when you switch to 6 axis mode, switch to regular cartesian movement. Then regular G1 moves will move each axis linearly, and they will be in the move queue.
One problem is homing, as when switching kinematics, axes are marked as unhomed (I think). You could copy the actual axis positions (available in the Object Model, I think) into variables before changing kinematics, then apply them after switching with G92.
There may be other problems I haven't thought of, but I think you would then have smooth movement between lines of Gcode.
Ian
-
@droftarts Oh I like the idea very much.
Is there a G-code command that switches motion from delta to cartesian
Or do I have to create a new config. create file? -
@tkln to switch kinematics see https://docs.duet3d.com/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters
There is no Object Model value that holds the 'actual' axis position, rather than the XYZ position. So it is going to be necessary to home the machine once you have switched kinematics. At this point things start to get complex, as you'll need to remap the endstop pins as well, and provide M208 limits for each axis, amongst other things. It might be easier to treat it as two separate machines, and have separate configuration sets for each. To make this easier, and then switching between them more easy, use M505: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m505-set-configuration-file-folder
Ian