Endstops not stopping external drivers on the expansion header
-
I don't know if this might be relevant but when I changed my CoreXY to XYUV, after mapping the drives I had to move the axes maxima to a position in the gcode file that was after the M584 command. I see in the config.g that your M208 is before the M584.
Also this from the Wiki might be relevant.
"Assigning a drive using M584 does not remove its old assignment. Therefore, if you assign a drive that defaults to being an extruder drive, you should also assign the extruder drives explicitly as in the above example. Failure to do so may result in unexpected behaviour".
Edit. That's big printer BTW!
-
Ok so I switched back to the Ethernet and used the same SD card and verified that the firmware is the undated one and when homing the endstops do not trigger the motors to stop. I even swapped the min and max codes so the max comes first and still the same. Not sure what the deal is.
-
Please try disconnecting the endstop switches from the Duet. As you have configured them to be active high, this should make them all read as if triggered. Then try to home X or Y when it is not already in the home position. Does the motor move towards the homing switch, or not?
-
It moves to towards the switch. But they should not be moving at all. This is why I link it is the board. With my WiFi board the printer runs perfect. If I bypass the external drivers and the encoder and run them from the main board they operate as intended. It is only when using the breakout board for external drivers.
-
As soon as I have shipped the prototype laser filament sensors, I'll try to replicate your configuration and see if I can reproduce the fault.
-
I can ship you the board if you want.
-
I don't see how it can be a fault with the board. It is firmware that reads the endstop inputs and stops the motors when they are triggered during a G1 S1 move.
One other user reported a similar problem, but it appeared to go away when he changed his config file.
-
Would it be worth the time if I completely erased the board and re-flashed it via usb?
-
You could try it, but that rarely solves anything. OTOH you could try installing different firmware versions, e.g. 1.18.2, 1.19.2, 1.20 and 1.20.1RC2
-
I need to run my printer so I am going to put my WiFi board back in but I will make a bench test for it and keep trying things.
-
I have put your config.g and homing files on a Duet Ethernet on the bench, and I have been unable to make the problem occur. As soon as I trigger the X homing switch, the X homing button changes from orange to blue. The only difference I can see is that I don't actually have any external drivers connected to the expansion connector. I have the internal 5V regulator enabled.
I am wondering whether with the external drivers connected, the voltage on the 5V and/or 3.3V rail is dropping too low, and that is causing the problem.
Please can you do the following tests:
1. Confirm that when you try to home, triggering the X homing switch does not change the X homing button from orange to blue (as well as not stopping motion).
2. In DWC, go to the Machine Properties page and check that endstops 0 and 1 are showing as not triggered. Then use the "Send GCode" box to send G28. When the X and Y homing switches are triggered (but the motors do not stop), do they show as triggered on the Machine Properties page?
3. If you try to home with the external drivers disconnected, when you press the X homing switch, does the homing button still fail to change from orange to blue?
-
Just when I thought I killed the last hornet finally getting the 2130 to cooperate (more like me to cooperate) I have this same endstop issue while using the expansion port. I will try the above suggestions and report my findings. I have the latest 2.0FW
