Duex5 Endstop Issue

3DPrintingWorld

You only need singular values for linear axis in M350, M566, M201, M203, M906, etc

This was pointed out in in the last thread. I made some large changes in experimentation and I must have reverted back to multiple values. I'll change it back but I have already confirmed that it will not have an effect. I'm assuming it defaults to the first value given.

It does seem like a good idea to put the endstops on the same board as the driver, but I was just trying to keep the X, Y, and U drivers on the same board. If that does not matter, I will move the U axis stepper and endstop back to the WIFI and then move both Y axis motors and endstops to the deux5.

Can you confirm that its ok to split drivers that work in conjunction to together on different boards? I would like to move the filament runout sensors to the deux5 but the documentation says it will not work. If its not suggested, then dual filament sensors would not be supported with my setup as I don't see a way around it.

I guess I will try 3.2.2 to see what happens.

Phaedrux

@3DPrintingWorld said in Duex5 Endstop Issue:

Can you confirm that its ok to split drivers that work in conjunction to together on different boards?

Better to split X Y U than to split the drivers between a single axis, no?

Personally I would use the probe for leveling and abandon multiple endstops entirely.

3DPrintingWorld

@Phaedrux I am only using the probe to level Z. The other stepper motors each have a endstop; X, U, Y(left), Y(right). Four in total. I do use two endstops for the Y, that is required to square the gantry to the frame.

I have considered sensorless homing for the Y, which would free up to two spots on the WIFI. Another user in our group has had good luck with it.

Phaedrux

Ah yes, sorry, for some reason I took your other thread about independent z leveling as the reason you were wanting to use multiple endstops.

Sensorless homing may be a good option. It might take some tuning though.

martin7404

Something that just came to me.
I think a year ago during setting duex5 with my dual lifting extruder experiment in the documentation was stated to take power for the duex from the duetwifi terminal , not directly from PSU. I forgot about that when wiring Muldex and the power for duex comes from PSU, i think others did the same as far the wiring on the github scheme is like that. I wonder if that could be the reason. I do not belive so.link text

The only reason for some troubles could be having bad GND conection between 2 boards

fcwilt

@martin7404

Hi,

This is how I connect power to Duet 2/Duex combos.

Duet WiFi Power Wiring.jpg

The two wires connecting the boards are solid, the two wires from the power supply are stranded.

The goal was to keep the length of wire from each board to the power supply the same so both boards see the same voltage.

Frederick

NexxCat

I had a very similar issue when building my IDEX printer. I seem to remember finding information from @dc42 that the end-stops on the Duex2/5 were polled differently from those on the main Duet2 board. I just moved mine back to the main board and the issue went away.

The issue I had was caused by the end-stop status not changing correctly or becoming stuck as triggered when it wasn't. This caused failed homing on the U axis, or failure to do a second more precise homing move after the coarse one. I verified that it was the Duex by manually triggering the end-stop and monitoring its status in DWC, where you could see it sticking. As soon as I moved it to the Duet2, it worked flawlessly.

martin7404

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

3DPrintingWorld

@martin7404 Good catch! I remember seeing that too, but I must have spaced it when I did the wiring. The wires are about 100mm long so it might be ok but I'll change it anyways.

3DPrintingWorld

@NexxCat This sounds like the issue. I updated to 3.2.2 and homed it maybe 10 times and no problem so far but it can be intermittent. I test it some more today.

I would move it back to the WIFI but I was hoping to use two filament runout sensors so I don't have the room on the board for both if I do.

3DPrintingWorld

@martin7404 said in Duex5 Endstop Issue:

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

I did try moving all three z axis motors to the wifi but my leveling was the same.

fcwilt

@3DPrintingWorld said in Duex5 Endstop Issue:

@martin7404 said in Duex5 Endstop Issue:

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

I did try moving all three z axis motors to the wifi but my leveling was the same.

Then what ever issue you are having is very likely related to the endstop sensors and/or the wiring.

I have my 3 Z steppers and Z endstop sensors connected to my Duex5 and they all work without problem now that I am running firmware 3.2.2.

Frederick

3DPrintingWorld

I have not seen this issue repeat since installing 3.2.2. Despite it being bad practice to have the endstop on a different board then the stepper. I will keep a eye on this should nozzle alignments not stay consistent as I often do multi material printing. The end goal is to move the y-axis to senseless homing which will make also room on the mainboard for the remaining endstop.

dc42

@3DPrintingWorld said in Duex5 Endstop Issue:

Despite it being bad practice to have the endstop on a different board then the stepper...

It's not bad practice, except that on Duet 3 there is one combination that is currently unsupported (endstop connected to main board and motor connected to expansion board).

3DPrintingWorld

@dc42 said in Duex5 Endstop Issue:

It's not bad practice

Ok, good to know! I would consider this problem solved since I am not seeing any issues since updating to 3.2.2