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

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.