Knock-on from bad wiring, board blown?
-
I purchased a full 3d printer kit including a Duet3D 2 WiFi and a BLTouch sensor. The sensor is the latest version with the separate plug in connector cable.
I didn't notice that, straight out of the box, the plug had been wired up wrong (black /white on left and yellow/orange/brown on the right).
I plugged in all my cables (sensors, motors, etc...) according to the manufacturer's instructions. When I powered up, something was obviously wrong. Only the blue LED was on. LCD panel stayed dark.
I powered down, disconnected the power supply and tried the USB socket. I was able to communicate with the board, update the firmware and even connect with WiFi.
Swapping back to the dedicated power supply, still only the one blue LED. No web interface.
I then disconnected ALL externals and powered it up again. Now all three LEDs came on and I was able to connect through the web interface.
By reconnecting things one by one I traced the fault to the BLTouch. Everything else appeared okay when connected. The LCD booted up and responded to touch input.
After some googling I realised the BLTouch was blinking slow red (failure to self initialise) and that it was wired up wrong. I corrected the wires in the plug, reconnected it and poeered on. Now the sensor flashes rapid red (hardware failure).
I ordered a replacement BLTouch whilst waiting for my warranty claim to be processed. The new sensor also only flashes rapid red. Further problems appear to be the LCD unable to connect to the board and the end stroke micro switches do not change state in the web interface.
Did something on the duet board get fried maybe?
The two critical bad connections in the original wiring were:
5v supply to sensor D.out
3v supply short to groundShould I add a replacement board to my warranty claim?
-
What state is the board in now? It sounded like it was working when the bltouch was removed, but now that you have a new bltouch it's not working completely?
If just USB connected are you still able to communicate with it via serial terminal?
What LEDs light up on the board when connected to VIN?
If you're able to connect to the web interface send M122 and M98 P"config.g" and post the results.
-
@phaedrux Here is the first part:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2.2 running on Duet WiFi 1.02 or later
Board ID: 08DLM-996RU-N8PS4-6J1DL-3SN6L-TST3R
Used output buffers: 1 of 24 (7 max)
=== RTOS ===
Static ram: 23460
Dynamic ram: 71476 of which 384 recycled
Never used RAM 16760, free system stack 192 words
Tasks: NETWORK(ready,237) HEAT(blocked,366) MAIN(running,453) IDLE(ready,20)
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:00:58 ago, cause: software
Last software reset at 2021-04-04 12:26, reason: User, GCodes spinning, available RAM 16760, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 25.5, current 26.1, max 26.4
Supply voltage: min 1.3, current 1.4, max 1.4, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: position 34982, ok, SG min/max not available
Driver 1: position 34982, ok, SG min/max not available
Driver 2: position 34982, ok, SG min/max not available
Driver 3: position 0, ok, SG min/max not available
Driver 4: position 0, ok, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-04-04 12:33:47
Cache data hit count 82373901
Slowest loop: 5.09ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.63ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 50:02:91:e5:3e:78
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25304
WiFi IP address 192.168.178.47
WiFi signal strength -44dBm, mode none, reconnections 0, sleep mode modem
Clock register ffffffff
Socket states: 0 0 0 0 0 0 0 0
ok
- WiFi -
-
@phaedrux
I can't enter everything as text in the comment because AKISMET says it's spam. I have uploaded a text file instead.(/assets/uploads/files/1617535285079-readout_20210404_r00.txt)
-
With the Bad BLTouch removed the board LOOKS like it's okay. All three fuses are still good.
However, with or without the Good BLTouch it is largely un-responsive.
The 'always on' fans spin up. The PWM Fan1 & Fan2 are off but Fan0 is currently always on.
Here is the board on VIN (no bad BLTouch):
Here is the board on USB (no bad BLTouch):
-
After more fiddling around I can give the following extra info:
The X and Y end stop microswitches now change the E0stp and E1stp LEDs on and off.
The Paneldue LCD is now responsive and offers me the option of homing the axes. However, it trips with an error that I need to check the IR Z probe and Paneldue before pressing the X microswitch.
As the new 'Good' BLTouch is currently also just flashing rapid red and I have no idea what needs checking on the Paneldue as it is bright clear and responsive (it displays a confirmation that the board is connected to WiFi even though the web interface is unable to connect), I can't complete the homing process.
-
@hickling said in Knock-on from bad wiring, board blown?:
However, it trips with an error that I need to check the IR Z probe and Paneldue before pressing the X microswitch.
What exactly does it say?
Your previous file upload didn't work. Try again or try copy and paste into the post again.
From the SD card please post the config.g, homeall.g and other homing files from the /sys folder.
I can't tell from your photos how the BLtouch is connected. But when the bltouch gets 5v connected it should power up and to a self test if it's vertical.
-
@phaedrux Okay, so I got the BLTouch to self calibrate. There was a twisted wire in the printer loom! Now both the new AND old sensors work.
The front panel is still unable to performing the homing procedure. Here is a picture of the exact message.
-
That message is coming from a user macro and not the firmware. What did you push before you got that message?
Hardware seems functional. For further help you'll have to provide some config files. config.g, homeall.g, homex homey homez bed.g and results of M98 P"config.g".
