Duet 3 BLTouch probing issues
-
hmm very strange.
to rule out a bad port, can you switch to io5?
-
i am on io4
-
i am out of real ideas why that is happening.
what firmware version are you running on the 3hc?
-
3.1.0 it came up as
-
lol it might be time to try to hire someone to do this for me. I never had issues before, but this thing is just kicking my butt.
-
Am I allowed to commission someone on here? Or put a bounty up? For real though I am debating it at this point.
-
You can do what you like, but the the paid help is the same as the free help.
I've looked at your config and you've already gone through any changes I would have made with the others.
I would suggest that the main issue is that it's an older version knock off BLTouch.
Can you send M98 P"config.g" and M122 please?
The only other thing I can think of would be to cut the trace on the BLtouch since it's one of the older ones.
And To try a different io port if you haven't already.
-
@Phaedrux said in Duet 3 BLTouch probing issues:
M98 P"config.g"
M98 P"config.g"
Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 265CM122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6JTD0-3SS6J-1V92V
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 163268 of which 76 recycled
Exception stack ram used: 224
Never used ram: 75044
Tasks: NETWORK(ready,1980) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4944) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:01:39 ago, cause: software
Last software reset at 2020-12-01 21:44, reason: User, spinning module LinuxInterface, available RAM 74660 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 41.9, current 42.1, max 42.4
Supply voltage: min 24.1, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Driver 0: standstill, reads 32230, writes 17 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 32230, writes 17 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 32236, writes 11 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 32231, writes 17 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 32231, writes 17 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 32238, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-12-01 21:46:18
Slowest loop: 4.37ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle 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
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.01ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0 sensor: no data received
=== CAN ===
Messages sent 364, longest wait 1ms for type 6018
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 2874/2876
SPI underruns 0, overruns 0
Number of disconnects: 1
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Trigger:
Finishing macro config.g, started by system
Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.39 - Ethernet -
-
Ill cut the trace and see what happens.
-
I think I missed this my first look through, but are you using an expansion board for your Z motors?
You will need to take a look at this:
Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.3.0.
If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.3.0.If that's the case, then I suggest you move the extruders to the expansion and move the Z axis to the main board.
-
I am using the expansion for the Z yes. I will take a look at that and swap them.
-
Ah yes i see what you mean. I'll get back to you.
-
That was it! OMG Thank You!
-
wait does that mean that now that my extruders are on the expansion the filament runouts wont work? thats fine i guess, but just so i dont go searching for a reason why if they dont
-
@Vampora they should work in 3.2 beta 4
-
@Phaedrux Gotcha.
