RRF3 and Duet wifi + Duex5

Phaedrux

; Z-Probe
M558 P9 C"^!zprobe.in" H10 F120 T6000         	; set Z probe type to bltouch and the dive height + speeds
M950 S0 C"duex.pwm1"                          	; create servo pin 0 for BLTouch
G31 P500 X172 Y186 Z2.5                         ; set Z probe trigger value, offset and trigger height
M557 X15:250 Y15:250 S20                        ; define mesh grid

You've changed too much.

M558 P9 C"^!zprobe.in" Remove the exclamation mark ! that's inverting the pin signal, so it's acting triggered when it is not. Leave the carat ^ to enable the pull-up resistor.

G31 P500 X172 Y186 Z2.5 The X Y offset is totally wrong. This is the distance between the nozzle tip and the probe pin. I highly doubt it's that far away.

See here for how to measure it. https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe#Section_Measuring_Probe_X_Y_Offset

Change G31 P500 to P25

When you send M401 and M402 does the pin deploy and retract? Post your deployprobe.g and retractprobe.g files.

Also, for good measure, please provide the results of M122 and M98 P"config.g"

beachtec

@Phaedrux

That is interesting. If I remove the inversion, nothing works. With it in, the probe functions, including M401 deploying and M402 retracting on command, reseting, and deploying for measurement (but it doesn't result in a measurement that I can see). But... I can follow direction


My_Nightmare :)
M122
Status
Idle
Mode: FFF
Tool Position
X
0.0
Y
0.0
Z
0.00
Extruder Drives
Drive 0
0.0
Speeds
Requested Speed
0 mm/s
Top Speed
0 mm/s
Sensors
Vin
24.2 V
MCU Temperature
37.6 C
Z-Probe
0
 Tools
 Extra
 Control All
Tool	Heater	Current	Active	Standby
Tool 0
T0 - Load Filament	Heater 1
off	21.1 C	
0
0
Bed	Heater 0
off	21.7 C	
0
0
Temperature Chart
Send code...
7/21/2020, 6:18:32 AM	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917Q9-GLMS8-6J1F6-3SJ6K-TGHW8
Used output buffers: 3 of 24 (21 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 94144 of which 84 recycled
Exception stack ram used: 264
Never used ram: 8600
Tasks: NETWORK(ready,384) HEAT(blocked,1216) DUEX(suspended,160) MAIN(running,1840) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:02:18 ago, cause: software
Last software reset at 2020-07-21 06:16, reason: User, spinning module GCodes, available RAM 8560 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00417000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 36.9, current 37.6, max 37.8
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-07-21 06:18:31
Cache data hit count 229401789
Slowest loop: 9.21ms; fastest: 0.14ms
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 1.9ms, write time 0.9ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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, 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 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 201.55ms; fastest: 0.09ms
Responder states: HTTP(2) 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 1
WiFi firmware version 1.23
WiFi MAC address 84:f3:eb:dd:cd:cb
WiFi Vcc 3.34, reset reason Unknown
WiFi flash size 4194304, free heap 18072
WiFi IP address 10.182.207.15
WiFi signal strength -50dBm, reconnections 0, sleep mode modem
Socket states: 0 4 0 0 0 0 0 0
=== DueX ===
Read count 0, 0.00 reads/min

JoergS5

@beachtec please try setting
M566 X1000 Y1000 Z10 E500
a higher Z value, because 10 mm/min means only 0.16 mm per second speed change. Please set to 50.

If it doesn't work after this change, can you please check wiring or make an image where you connected the wires? (to help checking)

beachtec

@beachtec

For completeness...

; deployprobe.g
; called to deploy a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time)
M280 P0 S10 ; deploy BLTouch
'''
; retractprobe.g
; called to retract a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time)
M280 P0 S90 ; retract BLTouch

The probe deploys correctly using any normal command. I do NOT get an indication of a z-probe value in DWC during probing and no control action. It will crash if allowed to do so.
Is it possible that something happened to the Duet "Z_Probe_in" channel? Is there a away to configure another GPIO pin to accept the signal from the BLTouch... or does this sound improbable?

beachtec

@JoergS5

I wish. The wiring is ok. I made a separate BLTouch loom and went around the existing wiring harness in place, with the exact same outcome.

duet image sized.jpg

beachtec

This post is deleted!

JoergS5

@beachtec the white and black cables look as if they are not at the left 2 pins, but the white in the air.
It's very difficult to check the other connections. I would connect the three PWM Servo cables to one connector of the Duex, not partly to the LCD connector. You have a condensator between 5V and ground, is this for a special reason?

beachtec

@JoergS5 They are 100% on the pins... but thank you . Sorry for the poor photo quality... the angle of the photo does make it appear that way! There is no cap/condensator between the +5 and ground. It is a connector with a shrink wrap sleeve on it (to reduce chances of accidentally pulling them apart. I have built 7 machines with the BLTouch, granted in the RRF2.x software. I have had issues with using the the 5v from the PWM connector that cleared up immediately with the move to the unused connector on the duet to power provide power. The BLTouch is responding to the PWM commands... in every case, except I can not get a trigger event to get the duet to "home".
BTW, I have a spare 3.1 BLTouch here... it's brand new. Swapping them had no impact.

JoergS5

@beachtec I would put the 3 servo cables together to one connector. Second I would check the cables: look at the 5 pin connector at the BLtouch and compare with BLTouch images in the internet which cable is which signal. Because sometimes the cables are switched.

I don't know whether you are "electronics-affine", but I saw people testing their BLtouch with Arduino Uno, to be sure the BLtouch is ok. E.g. https://www.3d-druck-community.de/showthread.php?tid=26431, but this is a german forum, but I'm sure there are english users doing this also.

JoergS5

@beachtec I think I've found something:

https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_name_format
the comment that using the duex.pwm1 syntax inverts the signal ("The DueX boards buffer and invert the signal. Therefore, when you use one of the forms prefixed with duex the firmware knows it has to invert the signal, but it doesn't invert it if you use one of the other forms"),

So you will probably need a ! in the M950 command if you use duex.pwm1.

There is another issue if you have Duex version 0.9 or 0.9a board, is this the case? Then check https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Duet_2_WiFi_Ethernet_with_Duex_2_or_Duex_5_expansion_board the switch setting.

Phaedrux

@JoergS5 said in RRF3 and Duet wifi + Duex5:

@beachtec I think I've found something:

https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_name_format
the comment that using the duex.pwm1 syntax inverts the signal ("The DueX boards buffer and invert the signal. Therefore, when you use one of the forms prefixed with duex the firmware knows it has to invert the signal, but it doesn't invert it if you use one of the other forms"),

So you will probably need a ! in the M950 command if you use duex.pwm1.

There is another issue if you have Duex version 0.9 or 0.9a board, is this the case? Then check https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Duet_2_WiFi_Ethernet_with_Duex_2_or_Duex_5_expansion_board the switch setting.

That's all for the servo control for the pin though, which in this case is working.

The signal for triggering is the white wire to the probe in pin. Try swapping out that wire because it seems like it's showing triggered even when it is not. You won't typically be able to see the trigger status change in the DWC display because the BLTouch triggers and resets instantly, so the display doesn't usually have time to register it.

The best way to test is the dynamic test described here: https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe

By the way it looks like you may have a cloned board.

beachtec

This post is deleted!

A Former User

@beachtec said in RRF3 and Duet wifi + Duex5:

How am I supposed to know it is a clone?

Its a "risk" when buying outside the authorized resellers I guess; depending on your consumer laws it might be illegal to sell clones even privately so if you feel tricked then maybe look into your options there.

As far as being able to tell its a clone, the top silk screen says "Based on Duet 2" instead of just "Duet 2", and the bottom will likely clearly state its a reproduction that is not support / endorsed by Duet3d.

That being said, as you've already experienced both the community and Duet3d will still support you with the firmware on a best effort basis

Phaedrux

Yes we'll do our best to help, we just can't provide warranty obviously.

It shouldn't be necessary to invert the signal of the Bltouch, and when you run without the inversion it's telling you that it's showing as triggered even though it's not. Which I believe. If it's not wiring then I suspect something is wrong with the probe, but you've said you've also tried swapping out a different working BLtouch and it has the same problem, which means maybe it's the board? Not sure.

Have you tried without the pull up resistor enabled? Remove the ^ from the M558.

JoergS5

My recommendation would mean some work...
You have too many options where the error is, so to reduce the possibilites, I would remove the duex and use the connectors which are used most often (2 cables at zprobe, the 3 on the connector which is now used for the cable to Duex), testing with the newly bought BLtouch first.
Then I would build a test station with the help of an Arduino Uno to make sure the Bltouch and cabling is working correctly. I'm sorry it's in german, but something like this project: https://www.3d-druck-community.de/showthread.php?tid=26431 This way you could reduce 3 possible error reasons (Duex, BLtouch, wiring). The attached bltouch.zip has english comments.

One additional idea: I have genuine BLtouch, but I have also a clone BLTouch (Geeetech). The clone has one speciality: I can turn the top allen key screw (the key at the top of the BLtouch which moves the core) as much as I like, more than the documented 180°. When turning a lot of turns, the pin becomes unmovable, so retract/deploy doesn't work any more. Maybe the core position is wrong at your BLtouch. That the pin of your BLtouch is bent, is another possibility.

beachtec

@JoergS5 Thank you all for your help here. It is certainly multivariate! I am going to pull it apart this weekend and bench test it... but I am leaning toward some sort of board failure and less a config error. I did learn allot (and I hope others did)... including the bit about the oft missing aux power jumper on the Duex board... completely explains why I have seen a missing 5v rail in the PWM ports there in the past. Those zingers in plain sight are the worst. I will post what I find. Thank you!

JoergS5

@beachtec Good luck! And I'm curious what it is.

beachtec

I finally got back to the Railcore RRF3x issue and ended up pulling my boards... @Phaedrux mentioned the Duet WiFi was a cloned board... and I think that was the problem. I put in a genuine Duet board I had on hand it is has been working without a hitch. It is POSSIBLE that the very act of the board R&R corrected a wiring issue (intermittent connection) or the like... sometimes it is hard to tell if things are terminated properly. Overall a great learning... nothing gets me from rote knowledge to understanding faster than solving challenging problems - cheers.

p.s. thx to @JoergS5 too for the help!