Z (U) axis moves while moving only x or y?

scottpickstock

Hi, So I have just set up dual z axis on my Cartesian printer, the type with dual end stops and all seemed to be working well during simple testing. my issue is though that when I mover the Y or X in say 10mm increments at some random point the Z(U) will move up 10mm, but only the U axis.

https://youtu.be/gSHhefFFDCY

Y +10MM can equal Y+10 & Z(U) +10MM, I can then press the Y+10mm again and it will go Y+10mm and Z(U) -10mm back to end stop.

it happens on both the x & y randomly but when the z(u) axis goes up 10mm the next click of say x+10mm will bring the z(u) axis back down.

hope that explains it well.

any help much appreciated.

; Drives
M569 P0 S0 ; Drive 0 goes backwards
M569 P1 S0 ; Drive 1 goes backwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S1

M584 X0 Y1 Z2:3 U3 E4 P3

M16 X16 Y16 Z16 U16 E16 I1 ; Configure microstepping without interpolation
M92 X80 Y80 Z400 U400 E800 ; Set steps per mm
M566 X900 Y900 Z12 U12 E120 ; Set maximum instantaneous speed changes (mm/min)
M203 X9000 Y9000 Z180 U180 E1200 ; Set maximum speeds (mm/min)
M201 X1000 Y1000 Z250 U250 E250 ; Set accelerations (mm/s^2)
M906 X850 Y900 Z850 U850 E850 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 U0 S1 ; Set axis minima
M208 X300 Y300 Z400 U400 S0 ; Set axis maxima

; Endstops
M574 X1 Y1 Z1 U1 S0 ; Set active low endstops

; Z-Probe
;M558 P0 H5 F120 T6000 ; Disable Z probe but set dive height, probe speed and travel speed
;M557 X15:285 Y15:285 S20 ; Define mesh grid

GizmotronX5000

@scottpickstock Is there a reason you have the extra Z motor set up as a U axis? I believe:
M584 X0 Y1 Z2:3 E4 P3 (no U)
will give 2 motors to your Z axis so they will always move together.

deckingman

@gizmotronx5000 He's got two end stops so wants them to move independently - at least when homing.

scottpickstock

@gizmotronx5000

As the other chap said, I have 2x end stop switches so the P3 parameter hides the u axis and the z2:3 couples them together. In the home.g and home.g there is a M584 Z2 U3 P4 which separates them, they then home separately before an m584 Z2:3 P3 which syncs them back up.

Homes fine, but somthing is amiss.

deckingman

So, I don't think you can have Z mapped to 2 and 3 as well as U being mapped to 3. I don't use multiple Z screws but I do have dual CoreXY gantrys. So my mapping is

M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3;

Which means that X uses motors 0 and 3 and Y uses motors 1 and 4 and U and V are hidden. BUT, for homing, the drives are re-mapped as follows:

M584 X0 U3 Y1 V4 P5;
That line is at the start of the homing file, then at the end of the homing file, they are mapped back to X0:3 Y1:4 etc.

So I'd say you need to do something similar.

Edit - so leave out the U from config g and just have M584 X0 Y1 Z2:3 E4 P3
Then in your homing file, start with M584 X0 Y1 Z2 U3.

scottpickstock

@deckingman said in Z (U) axis moves while moving only x or y?:

So, I don't think you can have Z mapped to 2 and 3 as well as U being mapped to 3. I don't use multiple Z screws but I do have dual CoreXY gantrys. So my mapping is

M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3;

Which means that X uses motors 0 and 3 and Y uses motors 1 and 4 and U and V are hidden. BUT, for homing, the drives are re-mapped as follows:

M584 X0 U3 Y1 V4 P5;
That line is at the start of the homing file, then at the end of the homing file, they are mapped back to X0:3 Y1:4 etc.

So I'd say you need to do something similar.

Edit - so leave out the U from config g and just have M584 X0 Y1 Z2:3 E4 P3
Then in your homing file, start with M584 X0 Y1 Z2 U3.

On the face of that didn't seem to work, without defining U3 the stepper would not move.... I can not continue testing for a bit as for the 3rd time today my config.g file has gone.....keeps timing out and some how the config,g file goes.

scottpickstock

@deckingman said in Z (U) axis moves while moving only x or y?:

So, I don't think you can have Z mapped to 2 and 3 as well as U being mapped to 3. I don't use multiple Z screws but I do have dual CoreXY gantrys. So my mapping is

M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3;

Which means that X uses motors 0 and 3 and Y uses motors 1 and 4 and U and V are hidden. BUT, for homing, the drives are re-mapped as follows:

M584 X0 U3 Y1 V4 P5;
That line is at the start of the homing file, then at the end of the homing file, they are mapped back to X0:3 Y1:4 etc.

So I'd say you need to do something similar.

Edit - so leave out the U from config g and just have M584 X0 Y1 Z2:3 E4 P3
Then in your homing file, start with M584 X0 Y1 Z2 U3.

I will say though for the most part it was working, during homing they both home to the switches then on moving z in the control area they worked fine, just some how x and y occasionally control it.

deckingman

@scottpickstock Yes, sorry. I got that a bit wrong. You need to define U in config.g but to an unused axis - say U10. So you have M584 X0 Y1 Z2:3 U10 E4 in config.g (and at the end of your homing files) . Then at the start of your homing file you put M584 X0 Y1 X2 U3.

I think that should work.

deckingman

As for losing your config.g file - might be a corrupt or faulty SD card? It's certainly not normal behaviour and could be related to your issues. If you are losing the config.g file, it might also be getting corrupted which could explain your movement issues.

scottpickstock

@deckingman

I have just done that very thing, I read an old thread where dc42 said to assign it to an unused driver, thing is it still does it, im thinking (that's dangerous as im no expert) that a simple G1 X10 shouldn't interfere with any other driver. I have just typed in G1 X10,20,30,40....all the way to 180 and it still did it. weird.

BTW dc42 said to do that to avoid any accidental U commands....or something to that effect.

weird how its still doing it when u is assigned to driver 9 (exluding the homez and homeall).

as for the SD card its worth trying, is it easy to do, am I able to just transfer everything over or is there a special procedure?

scottpickstock

Here is a short clip, im using matter control to move the x axis in 1mm increments and as you will see the u axis is moving up and down on its own accord.

that's with U configured to driver 9 in config,g, one other note is its not running within the limitations set in config.g as its moving hella fast.

https://youtu.be/gSHhefFFDCY

dc42

I believe this has already been fixed in firmware 2.01beta2.

scottpickstock

@dc42 said in Z (U) axis moves while moving only x or y?:

I believe this has already been fixed in firmware 2.01beta2.

The current FW is "Firmware version 2.0(RTOS) (2018-06-05b3)

Just realised you typed 2.01 beta, is this a known issue already? Searched and searched but couldn't find anyone with the same problem.

I will look into swapping the FW out.

Thanks.

dc42

There is a known issue that may occur when an axis such as U remains mapped to a driver after it has been used for homing and then hidden. To avoid it, when you assign both drivers back to Z after homing, assign U to a non-existent driver number. That will deal with the worst effects, although motion speeds may still be affected occasionally. To avoid the effect completely, map U to a non-existent driver, and don't hide it. Or upgrade to 2.01beta2.

scottpickstock

@dc42

that's great, I will try the easy option first as a test then look at the slightly more complicated option of updating of the firmware.

much appreciated.

scottpickstock

just an update,

so, I first changed the code to assign U back to driver 9 after homing and this sorted the z axis moving up on the u axis while jogging x or y. however, I had a new issue in that when I move z up 10mm it doesn't move …..the y axsis moves instead, when I then move the y axis +10mm I can only move it back 10mm and no further as it thinks its position is +10mm from 0 when its now actually +110.

on updating to 2.01 beta that issue is still present, I will go through the files again and do some tweaking to see if I can sort it.

any more advise in the meantime is welcome otherwise I will be back with an update.
EDIT: once again my config.g file has gone, 5th time in two days. Hmmmmm

scottpickstock

@scottpickstock

second update.

so it seem my previous issue of the y moving while jogging z could of been (most probably defiantly) my fault. While tidying up the code I noticed in home.z I had put m5...something something X0 Z1 Z2:3 U9 E4 P3.

Anyways I have cleaned it all up and so far everything is fine.