Duex5 Endstop Issue

[fcwilt]

@3DPrintingWorld said in Duex5 Endstop Issue:
If the U axis is not moved away from the endstop, while homing the Y it will pull the U axis towards the endstop because of the way the Dual markforged kinematics work.

Well I don't know what sort of arrangement you have but having U axis motion as a "side effect" of homing Y does not sound right.

Can you post a diagram of the motion system as used on your printer?

Thanks.

Frederick

[3DPrintingWorld]

@fcwilt The Kinematics are correct, not really in question.

M669 K0 Y1:1:0:1. 

Its a 0:1 or 1:0 arrangement depending on direction of travel of the Y axis.

The issue is the U axis is not stopping at the endstop correctly when connected to the duex5. I dont think the type of kinematics plays a role. Perhaps I gave TMI.

[Phaedrux]

@3DPrintingWorld said in Duex5 Endstop Issue:

M350 X16 U16 Y16 Z16 E16:16 I1 ; configure microstepping with interpolation M92 X100.00 U100.00 Y100.00:100.00 Z1096 E415.00:655.00 ; set steps per mm (1760nimble) M566 X1000.00 U1000.00 Y1000.00:1000.00 Z100.00 E100.00:300.00 ; set maximum instantaneous speed changes (mm/min)(Nimble 40) M203 X12000.00 U12000.00 Y12000.00:12000.00 Z2000.00 E4200.00:4200.00 ; set maximum speeds (mm/min) M201 X800.00 U800.00 Y800.00:800.00 Z100.00 E600.00:600.00 ; set accelerations (mm/s^2)(500)(Nimble 120) M906 X700 U700 Y700:700 Z200:200:200 E600:600 I30 ; set motor currents (mA) and motor idle factor in per cent(Nimble 500) M84 S30

You only need singular values for linear axis in M350, M566, M201, M203, M906, etc. It's only extruders that require those values to be defined per drive. Once the driver has been assigned to an axis, you only need to define the settings per axis.

3.2.2 did fix some issues with endstops triggering very close together. So updating to 3.2.2 would be a good thing to test.

Also something to keep in mind with the duex is that it's usually a good idea to try and keep the Z axis motors and endstops together on the same board, probably the main board. So in your case you could have Y and Z on the mainboard and X U E on the duex. That may help avoid any timing issues.

This may also help with your other thread on independent Z leveling.

[3DPrintingWorld]

@Phaedrux said in Duex5 Endstop Issue:

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.

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