[3.4.0beta6] Home/Limit switch bug
-
@t3p3tony It happens only if any limit switch is depressed on startup!
What actually bother me most is that after the electronics repositioning I had a broken wire in one of the limit switches connectors, just by the pin so barely not easy to spot. My limit switches are microswitches, used as NC to reduce effects of electrical noise, and thus it looked actually like a triggered switch. With the new electronics position it was quite difficult to see the LEDs on the board.
Of course, a much clever configuration, with extended homing scripts, could be applied to circumvent the situation and gracefully signal the problem. But, still, it is a hidden bug in the end!
-
@catalin_ro Does it happen if the carriage is in the centre and you manually hold down the switch. Does it happen for all axis?
Please can you add your config.g, homing macros and anything that they reference here.
-
@t3p3tony It doesn't matter where the carriage is. As long as a limit switch is triggered, no matter how it is triggered, I see the problem.
If any limit switch is triggered, all axes that involve movements while homing show the error - I have a B axis that is rotational and it doesn't have any switch/homing indicator.
I will share tomorrow the config.g and the homing files. Now the CNC is powered off.
-
@t3p3tony As promised, here are the various configuration files.
config.g
; General preferences M111 S0 ; Debugging off M453 ; CNC mode G21 ; Work in millimetres G90 ; Send absolute coordinates... ; Touch probe configuration M558 P5 C"!^zprobe.in" H5 F100 T2500 A5 S0.01 ; Set Z probe type to switch and the dive height + speeds G31 P600 X0 Y0 Z0 ; Set Z probe trigger value, offset and trigger height M557 X15:530 Y15:500 S20 ; Define mesh grid ; Drives & Axis ; ; Define axis X on drive 0, axis Y on drives 1 and 4, axis Z on drive 2 and axis B on drive 3 M584 X0 Y1:4 Z2 B3 ; ; Set stepper drives parameters for all the used ones M569 P0 S1 ; Drive 0 goes forwards M569 P1 S0 ; Drive 1 goes backwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S0 ; Drive 3 goes backwards M569 P4 S0 ; Drive 4 goes backwards M350 X16 Y16 Z16 B16 I1 ; Configure microstepping with interpolation M906 X2400 Y2400 Z2400 B2400 I50 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; ; Set axis dynamic parameters M92 X400 Y400 Z400 B888.89 ; Set steps per mm M566 X400 Y400 Z12 B12 ; Set maximum instantaneous speed changes (mm/min) M203 X2500 Y2500 Z2500 B3060 ; Set maximum speeds (mm/min) M201 X150 Y150 Z150 B150 ; Set accelerations (mm/s^2) ; ; Set per-axis travel distances M208 X0:545 Y0:780 Z0:120 B-360:360 C0:530 ; ; Set axis endstops M574 X1 S1 P"xstop" ; Set X active high endstops M574 Y1 S1 P"ystop+e1stop" ; Set Y active high endstops M574 Z2 S1 P"zstop" ; Set Z active high endstops M574 B0 ; Set B no endstops M581 X Y Z S1 T0 R0 ; Enable endstop triggers ; Network M550 PWorkBee ; Set machine name M540 PBE:EF:DE:AD:FE:ED ; Set MAC address M552 P192.168.1.200 S1 ; Enable network and set IP address M553 P255.255.255.0 ; Set netmask M554 P192.168.1.254 ; Set gateway M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Miscellaneous M501 ; Load saved parameters from non-volatile memory ; Enables the spindle PWM controlled through fan 1 PWM M950 R0 C"fan1" L24000 Q1000 M563 P0 R0 S"Spindle" T0 M3 S1000 M5 ; Change to workplace coordinates set 1 G54
homex.g
; homex.g ; called to home the X axis ; ; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time) M581 T0 R-1 ; disable trigger for endstop X G91 ; relative positioning G1 H1 X-1500 F1000 ; move quickly to X axis endstop and stop there (first pass) G0 X5 ; go back a few mm G1 H1 X-100 F100 ; move slowly to X axis endstop once more (second pass) G0 X1 ; go back a few mm G90 ; absolute positioning G53 G92 X0 ; reset the X coordinate G54 M581 T0 R0 ; enable trigger for endstop X
homey.g
; homey.g ; called to home the Y axis ; ; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time) M581 T0 R-1 ; disable trigger for endstops Y G91 ; relative positioning G1 H1 Y-1500 F1000 ; move quickly to Y and C axis endstops and stop there (first pass) G0 Y2 ; go back a few mm G1 H1 Y-10 F100 ; move slowly to Y axis endstop once more (second pass) G0 Y1 ; go back a few mm G90 ; absolute positioning G53 G92 Y0 ; reset the Y coordinate G54 M581 T0 R0 ; enable trigger for endstops Y
homez.g
; homez.g ; called to home the Z axis ; ; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time) M581 T0 R-1 ; disable trigger for endstops G91 ; relative mode G1 H1 Z300 F1000 ; move Z towards the switch until it triggers G0 Z-5 ; move Z back 5mm G1 H1 Z10 F100 ; move Z slowly towards the switch until it triggers G0 Z-0.5 ; move Z back 0.5mm G90 ; back to absolute mode G53 G92 Z{move.axes[2].max} ; reset the Z coordinate G54 M581 T0 R0 ; enable trigger for endstops
homeb.g
G92 B0
-
@catalin_ro said in [3.4.0beta6] Home/Limit switch bug:
M581 X Y Z S1 T0 R0 ; Enable endstop triggers
The only thing that sticks out to me is the use of triggers for the endstop switches. Maybe something is going on with that. It seems like that shouldn't matter since they are disabled during homing.
-
@phaedrux The homing switches are also used as safety limits, thus there is a small retraction before resetting the coordinates. In series with the homing switches, there is another set of switches that are really used as safety limits.
The trigger based solution is the most simple that insures an abrupt stop if any switch is activated when it shouldn't.
-
@catalin_ro Yes, but set the M581 T0 say at the end of homeall.g. If you put it in config.g you will cause a reset loop. You will also need to cancel it at the beginning of homeall.g in case you run it more than once.
-
@theolodian The reset loop is something that I have also seen and I properly understood immediately. The problem is that if the board is powered on with any homing/limit switch triggered, it doesn't enter the reset loop and, instead, it falsely reports issues with the steppers.
While I intend to make a lot more clever homing scripts, separating the homing and limits switches electrically (different inputs) and not enabling the triggers for an axis until homes, the problem is still there...
-
More to this...
Just upgraded to 3.4.0beta7, mostly out of curiosity. Immediately after the update everything looked OK. I homed the machine several times without a glitch.
So I decided to do a minor change in the config.g file. I saved it, soft rebooted the machine and there it was! The problem hit me again...
In the end I was able to get rid of the issue after a quick series of power cycles. As previously observed, once properly started, everything worked flawlessly.
As this time I had no homing switch triggered that brings me to a very poor conclusion - somehow the Duet board degraded over time and in certain situations it starts to wrongly indicate motor related errors. I do not suspect issues related to its relocation after upgrading the machine as I have moved it along with its support structure.
Overheating is not an issue for sure. Last time I have extensively used the machine about 6 months ago, with environment temperatures not exceeding +30°C. These days, the room where it is located is at a rather cool 21-22°C and there is a fan continuously cooling the whole board. No matter what I do, the CPU never reports more than 31°C. I don't suspect any of the drivers getting too hot, especially while doing these simple homing tests.
Is there any way of getting around the phase disconnected check in the Trinamic drivers? Right now it seems to be mostly a bogus error more than anything else. Or should I consider getting a new controller?
-
@catalin_ro at what movement speeds do the "phase may be disconnected" warnings happen? Bogus warnings most commonly occur when the movement speed is quite high and the back EMF from the motors at that speed is greater than the power supply voltage. So if the warnings have only started recently, check that the power supply voltage is good and that the VIN connections to the Duet are sound.
If you only see warnings from one phase and it is always the same phase, then most likely the warning is genuine and you have a bad connection to that phase.
-
@dc42 It always happens when trying to home the machine after a software reset. Right now I can easily reproduce it:
- power on the whole machine
- do a homing cycle - everything is OK during this run if none of the end-stops is triggered
- do an emergency reset through the web interface
- try to home again the machine - the errors start popping up
I can't blame it any of the connectors because the errors do not come up after the initial power on. Also, if instead of trying to do a complete homing sequence I try to home a specific axis, the errors will come up for that axis. Even more, as I have a dual-Y setup, when I try homing the Y axis, the errors come up for both drivers/steppers.
Once the machine is homed, I can used for days with no errors!
More to that: the machine is a QueenBee mechanics (similar to WorkBee), with high torque steppers left from the original WorkBee - 3A, 4mH, 1.2Ohm.
-