Z-drives not moving, new Duet3

Heide

@joergs5 I will change this tomorrow. But I'm sure that I have already tried it. (I have tried so many things today)

JoergS5

@heide said in Z-drives not moving, new Duet3:

tried it. (I have tried so many things today)

The risk is high that you mixed something up by trying different things.

First thing to check is that G1 H1 X-100 and Y-100 move your hotend into the correct direction toward the endstops. Then please try my proposal.

What I do if I am not sure about correct codes, I run them line by line directly in the DWC command line and check that in this case the first, second, third endstops are triggered as expected. There are a few G-Code commands which can be run only in a specific order (drive additions and their mappings), but most commands can be tested this way.

Heide

@joergs5 I will, and I am aware that it is posible to mix up code. But every time I change it to something else, I whipe the code and saves it i Word. Then I can retur to it later. Then I try a New code. But the ideer about taking a step at a time is brilliant. Did'nt think in that direction

droftarts

@heide said in Z-drives not moving, new Duet3:

Error: Bad command: Put G/M Codes in here to run when Tool 0 is about to be activated

Just to explain this error; you have T0 in your config.g, so the tool change macros get run. As no tool is selected, only tpre.g and tpost.g are being run. It looks like the text at the beginning of one of these files is not commented out correctly, with a semicolon ; as the first character.

I've had a good look at your files, but I can't see what's stopping the homing working. I think try @JoergS5 suggestion of stepping through the GCode of homeall.g and homez.g, and see what works correctly and what doesn't.

Ian

Heide

@droftarts thanks for the time you have used. And I am really sad that there are no errors, because I then maybe have a problem. I just can get it. It can run with no errors, with the code I postes earlyer today, when I tested. I will do as @JoergS5 proposed.

JoergS5

@heide said in Z-drives not moving, new Duet3:

G1 H1 X-240 Y-240 F3000

I have two additional ideas for your tests. The -240 will probably not be sufficient, because your M208 says the axes are 300 long, so I would take higher values. The goal of this line is that one of the endstops is triggered.

The second idea is, when I run G1 commands in the DWC command line, I prefix G90 or G91, so I am sure the command runs in the correct mode. E.g.:
G91 G1 X100
This is important in the homeall, because there are several changes of G90 G91 inside. (NB: I don't mean that homeall is wrong: the G91 G90 sets mode for the following lines. I mean, to be sure you're in the right mode when executing it line by line)

Heide

Okey, what I know for now, is that it seems that the endstops X and Y prohibit the gantry to move after they are activated, it is like they hold on to it (locks it). I tried to force (not my intension, but needed to see if I could move the gantry when I did) the gantry away form the endstops (X and Y), and then I can move it. I will need to test some more, but that must be later. (Need to be somewhere else) But I will be back I'm so happy for this community, and your help, I hope I can contribute some day

Heide

Another Thing I forgot to mension. The endstop is a Hall Effect type

JoergS5

@heide if you post a picture of the endstops, someone may tell you from experience what can be the reason for the locking.
I am pleased to hear that you are approaching a solution.

droftarts

@heide said in Z-drives not moving, new Duet3:

@droftarts And I am really sad that there are no errors, because I then maybe have a problem.

Don’t be sad! There is probably an error, just I didn’t see it. Use this as a learning experience!

Ian

Heide

@joergs5 this is the endstop

https://docs.vorondesign.com/community/electronics/120decibell/hall_effect_endstop_setup.html

JoergS5

@heide the only information I found is in https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_endstops that the 5V wire should be connected to 5V of the IO connector, but you've probably done that already.

Heide

@joergs5 happy to have pictures on my Phone when I'm not at home. This is the connection for the Hall sensor. And I think it is corrct connected

Heide

The yello Wire has common GND from the other connnection

JoergS5

@heide if the blue wire is 5V, than it's correct. (the colors differ from the Voron page, you should check it. Often, red is voltage, black is ground, other colors are signals. But if you DIY wiring, you can choose colors as you like. Your wires black-red-yellow-blue)

Gixxerfast

@heide Hi, if you're using the hall effect sensor in its default location, may I ask why you define your X and Y endstops to be low end?

Normally on a Voron, the X0 and Y0 is front left corner of the bed. And you home at max X and Y.

Here's my endstop configuration:

; Endstops
M574 X2 S1 P"121.io0.in"                       ; configure active-high endstop for high end on X via pin 121.io0.in
M574 Y2 S1 P"0.io1.in"                         ; configure active-high endstop for high end on Y via pin io1.in

However, I do not use the hall effect, but that's just an inverse away.

Also, a simple M119 will tell you all you need to know, one where they should be activated and one where they should not be.

Heide

@joergs5 yes that correct. I was confused about that. But the wires was made when I recieved the Kit. But I did have to change the plugs, to work with the board. As you can see the red wire has a label with an X or a Y. Can't remember

@gixxerfast on my Voron the endstop i placed under the gantry on the right bottom side. X i homed in that right position offcause, but Y is homed when the Gantry moves to the bottom, on a fixed magnet that is placed on the Z3 liner.

Heide

The Hall effect sensor is wired correctly.

Heide

@Gixxerfast I was on a small road trip when I read you text, and have misread it. I have now read it again, and can see that I also have the high end in the bottom of the right side. I will now reconfigure the Config and home files to this. Let see if this helps

Heide

I have now tested all possible variations, high and low end with and with out ^!. It stops working after homing X and Y.

Now I'm thinking it could be the endstop of Z that is blocking, not the X or Y. It would make sence, since it stops there. If it sees the endstop on, then it won't go. Or maybe the signal should be inverted. I will try this tomorrow.