Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home
-
@Thalios I have tried io5 yes, didn't work. Could you please share your relevant rows from config.g for anything to do with the BL Touch and endstops. Also your deploy/retract probe.
What version of the BL Touch do you have? Confirm you have a Duet3 with v3.1.1?
Thanks!
-
@Phaedrux - I have a lot to learn yet, so appreciate the input. I can't state with much confidence that anything about my configs is correct yet. I'm just in the commissioning phase of "getting things to move, or blink" and hoping that nothing goes "bang!"
Once I get through the BL Touch issue, I'll feel at least in control of the basic functions, and can then learn and refine as I start to do the calibration work.
-
Can you provide the results of M122 and M98 P"config.g"?
Are you using the Duet 3 in SBC mode?
; Endstops M574 Z1 S2 ; configure Z-probe endstop for low end on Z ; Z-Probe M950 S0 C"io5.out" ; create servo pin 0 for BLTouch M558 P9 C"^io5.in" H5 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds G31 P500 X0 Y0 Z2.5 ; set Z probe trigger value, offset and trigger height M557 X15:215 Y15:195 S20 ; define mesh gridM280 P0 S10 ; deploy BLTouch M280 P0 S90 ; retract BLTouchHave you seen the BLTouch 3.1 manual?
https://5020dafe-17d8-4c4c-bf3b-914a8fdd5140.filesusr.com/ugd/f5a1c8_d40d077cf5c24918bd25b6524f649f11.pdfOr seen this?
https://www.antclabs.com/logic -
OUTPUT FROM M122:
m122
=== 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-NA3TJ-6J9DL-3S86J-9T9AT
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162760 of which 60 recycled
Exception stack ram used: 224
Never used ram: 75568
Tasks: NETWORK(ready,1972) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4952) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:03:18 ago, cause: power up
Last software reset at 2020-10-21 11:50, reason: User, spinning module LinuxInterface, available RAM 75240 bytes (slot 2)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 16.2, current 28.4, max 28.5
Supply voltage: min 27.9, current 29.4, max 29.5, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: standstill, reads 59066, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 59066, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 59067, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 59067, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 59068, writes 14 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 59068, writes 14 timeouts 0, SG min/max 0/0
Date/time: 2020-10-21 23:54:43
Slowest loop: 3.90ms; 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: 0.83ms; 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
=== CAN ===
Messages sent 723, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 18ms ago
RX/TX seq numbers: 5844/5845
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 0.13
- Ethernet -
-
OUTPUT FROM M98 P"config.g"
10/22/2020, 6:55:46 AM 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 365C
Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 318C
Warning: M307: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 937C -
Yes, running with SBC - Pi4. Done all the apt-get update/upgrade stuff. Upgraded firmware on D3 to 3.1.1, validated that the Pi has all the relevant components versioned at 3.1.1 too.
-
If you're absolutely positive that the wiring is correct, I would suggest trying to setup the Duet3 in standalone mode just to take the Pi and DSF out of the equation entirely.
The easiest way to do this is to create a new SD card with the usual folder structure.
https://duet3d.dozuki.com/Wiki/SD_Card#Section_Creating_the_file_structureMake sure the /www folder has the contents of the DWC 3.1.1 files.
https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/DuetWebControl-SD-3.1.1.zipDownload your current config files from DWC by clicking the check box to select all files, right click and save as zip. Then extract that zip file into the /sys folder on your new SD card.
Place that SD card in the Duet 3 and disconnect the Pi ribbon cable.
Then test the BLtouch as described here.
https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe -
With respect to the following - I have seen the documents, but without being told anything is necessary, short of being instructed to do so, I've not done anything other than setup the config.g
Phaedrux Have you seen the BLTouch 3.1 manual?
https://5020dafe-17d8-4c4c-bf3b-914a8fdd5140.filesusr.com/ugd/f5a1c8_d40d077cf5c24918bd25b6524f649f11.pdfvistalert: Yes - I note with interest the text "Z trigger with adaptable width: "
Do you feel it's advisable to do something in this context? Has anybody had to do this with a D3, BL Touch 3.1?Do you guys have a D3 and BL Touch 3.1? I think I saw some posts previously that mentions you have tested this.
Or seen this?
https://www.antclabs.com/logicvistalert: Yes I have - Does the Duet3 fall into this category? "A board with a large capacity capacitor in the end-stop input circuit, such as the Melzi"
Being connected to io7 and +5v means that might BL touch out of the box should be good to go, no?
The only thing I can think of from the above documents is the pulse width comment.
I'd like to do any further changes on this premise, if possible:
- Has the Duet team tested BL Touch 3.1 with Duet3 and firmware 3.1.1?
- If yes, and it's working, what do I need to do to get to the same level of success?
- Given my wiring appears to be fine, either the BL touch may be faulty, or there is a comms / timing issue, as indicated by the PWM comment in the 3.1 documentation.
Does the above sound sensible?
I don't want to randomly go off trying stuff, as you guys lose control of the troubleshooting flow, and I may have or leave the device(s) in a dysfunctional or unknown state.
Happy to work step by step with "If you do this, what does M???? report" or "try this, expect this...."
Thanks.
-
No you're not the first to have some issues with the BLTouch 3.1. There were some issues when connected to the tool board that we are now aware of, but there have also been some cases with it not working as expected with the Duet3. It's also been reported to work fine, so further investigation is necessary.
The reason I bring up the manuals, etc is just to give us all the relevant information while we investigate.
It is certainly possible that the BLtouch is faulty. It wouldn't be the first time. Your config is correct, and you have checked the wiring, so either the BLTouch is faulty or there are some firmware issues with the 3.1 specifically. Both are possible.
I don't have further things to try other than my description of testing standalone mode and testing a new BLTouch. I've brought it to DC42s attention as well, so he may have some things to test soon.
-
Sounds good, and again, thank you. I actually run a tech support team myself, so I truly appreciate how difficult and challenging this is. I'm also willing to do what ever I can to assist...as my first message said, this is an awesome product, and I can't imagine trying to do this stuff if we had to keep flashing firmware. With RR, it's easy to quickly spin a config and diagnose.
I have actually ordered a second BL Touch. It may be here in a couple of days, fingers crossed. Just FYI, my dad (I'm 56, he's 80!) is a micro-electronics guru, and even he grilled me about the risk of bad wiring / crimping. He pointed out, even with continuity, it's possible to have too much resistance, as well as other issues. So we did carefully go through the connector pins and add some solder too to ensure a guaranteed solid connection. Just worth noting, as my initial confidence based on "continuity" isn't necessarily proof that there's nothing wrong with the cabling.
I don't feel inclined to do anything about logical level, as clearly the D3 supplies 5V, and the BLT3.1 seems to work that way by default.
I'm definitely interested in the PWM width comment.
Given I have a D3, and Pi 4, there's two high performing pieces of kit here. If the timing is out at all in the communications via the BLT OUT -> io7.in then there is something worth investigating there.
-
@Phaedrux and possibly for @dc42 to consider. I have a good collection of various Arduino / ESP and teensy boards here.
If you had a sketch (or link to) that might validate the BL Touch perhaps that would be a good troubleshooting / diagnostic step? I have Wemos D1 mini, which is 5V capable.
Just a thought.
-
@vistalert said in Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home:
I don't feel inclined to do anything about logical level, as clearly the D3 supplies 5V, and the BLT3.1 seems to work that way by default.
Well the reason I brought it us is just to assess whether it may have been changed at some point or if the 3.1 is behaving different to the previous versions. More for DC42 to answer since he has a 3.1 probe to actually test with.
@vistalert said in Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home:
Given I have a D3, and Pi 4, there's two high performing pieces of kit here.
That's part of the complication actually since it introduces another layer of software and hardware. Hence why I asked if it would be possible for you to switch temporarily to standalone mode to test since it would help isolate the problem if it is firmware related. It's also really handy to be able to switch back and forth for cases like this. Once the SD card is prepared it's as easy to switch between standalone and SBC mode as pulling the SD card and connecting the Pi again.
@vistalert said in Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home:
Just FYI, my dad (I'm 56, he's 80!) is a micro-electronics guru, and even he grilled me about the risk of bad wiring / crimping.
You're quite lucky to have that in your back pocket. I myself feel quite lucky to have my father (86 and a master mechanic, electrician, and carpenter. Wealth of knowledge.)
-
@Phaedrux
We are indeed very lucky. And it's remarkable how diverse our thinking and skills are. So I know we'll get there.Totally understand about the comms/timing.
Ah I misunderstood / skipped the standalone comment. I get your point. How would I go about that. I don't have a screen, which may be an issue in terms of user interface?
Before we try that, is there some GCODE I can execute which we think would give us an adjustment to the pulse width, or should we wait for dc42 to come back? Happy to do that.
-
For what it's worth if this was on a Duet2 and older BLTouch it would most certainly be an issue with the white wire.
@vistalert said in Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home:
Before we try that, is there some GCODE I can execute which we think would give us an adjustment to the pulse width,
Not that I'm aware of.
@vistalert said in Duet3 BLTOUCH3.1 Probe deploys but doesn't trigger on Z Home:
I don't have a screen,
Well if the Pi is running as a headless device with no GUI then it would be a bit trickier to get your configs off, but since we are just testing you could just as easily create a fresh set of configs using the online config tool just to get a basic config in place to test with.
https://configtool.reprapfirmware.org/Start
I also should have mentioned that the ethernet cable would need to be connected to the Duet3 as well so that we had network access to reach the web control.
-
@Phaedrux OK sounds pretty straight forward. I'll give it a shot.
Is there GCODE I can run that gets the probe current state?
Is it worth trying this? Have a shall script on the Pi that runs a loop to get the probe status, and it echos if it sees a non-zero value? I could deploy the pin and just keep tapping it repeatedly to see if I can ever get a 1000 reading or any non-zero value.
-
Well in the web interface there is a probe value display but the problem with the bltouch is that it only triggers for a split second before resetting so it's hard to catch it show 1000.
The best way to test it is the dynamic test described in the test and calibrate z probe link I posted earlier.
-
I have a 3.1 BL touch with Duet 3 6HC (actually, 3 of them) running RRF 3.1.1
config.g related to limits:
; Endstops M574 X1 S1 P"io1.in" ; configure active-high endstop for low end on X via pin io1.in M574 Y1 S1 P"io2.in" ; configure active-high endstop for low end on Y via pin io2.in ; Z-Probe M558 P9 C"io5.in" H5 R1 F120 T6000 A5 S0.02 B1 ; set Z probe type to bltouch and the dive height + speeds M950 S0 C"io5.out" ; create servo pin 0 for BLTouch G31 X-2 Y42 Z1 P25 ; Probe position and offset -
@Thalios thank you so much. This also appears to confirm, in conjunction with advice I received from another user group, that the BLT 3.1 doesn't require the pull up.
I have a few more tests to conduct now, and will revert back soon, to see if I can get this to work.
@Thalios - be a new comer to RR and GCODE generally. Can I please confirm your machine homes to front-left corner. Did you use mechanical or optical endstops? I have mechanical end stops on order, but currently using sensorless homing.
Does the order of M558 and M950 matter?
Did you do anything with the BLT 3.1, with reference to the comments in the documentation about having the pulse width variable, in case machines do miss the probe status? Or did you just run the BLT straight out the box.
One final question...so it's implicit that the BL touch is using PWM communication, so I am assuming the comms from the BLT back to the D3 is also PWM. It's not the case that the BLT is simply pulling io.in to HI state, is this understanding correct?
-
I'm not 100% sure about the M558 vs M950 order, but that's how i have it set because i think you need to define the probe and its pin before you can create the servo for it (M950).
As far as pulse width, I have not changed anything in there.
I do believe it is PWM, but don't take my word for it.
-
@Thalios re: 558/950 - makes perfect sense. Many thanks for the clarity and input.
