Creality CR Touch not triggering

Phaedrux

Check to make sure your wires are in the right place and that the crimps are good and that you're getting continuity end to end with a multimeter.

https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_connecting#creality-cr-touch-wire-colours

texastanker

@Phaedrux The colors for the CR Touch don't map the same as the BL Touch in that document. For example, the BL Touch white is out, and for the CR Touch white is ground. It took a lot of trial and error to figure out the mapping for the CR Touch. I will check the wire connections again but if I have them mapped wrong it would be great if someone would tell me the correct order because the document does not tell you the mapping to the pins for the CR Touch. Since M401 and M402 work I had assumed the problem was in the config file. Any help would be greatly appreciated.

Phaedrux

@Phaedrux said in Creality CR Touch not triggering:

cr-touch-wire-colours

Did you look at the CR touch portion? Is your CR touch different?

Based on the colors in there it would be the yellow wire sending the trigger signal.

texastanker

@Phaedrux Mine are the same as in the picture but the table that shows the mapping to the board pins is for the BL Touch only. They don't have a column for the CR Touch. So, I had to guess by mapping to the CR Touch OUT to the Board IN, CR Touch Control to the Board OUT, Ground to Ground, and Power to Power.

droftarts

@texastanker Does this picture match your wiring?
Touch
Because the Red and Blue wires are switched compared to our CR Touch wiring image:

That would make your wiring:

PCB pinout (Left to Right)	Out	GND	Control	+5V	GND
Creality CR Touch (most common order seen)	Red	Blue	Yellow	Black	White

So your wiring to the Duet is incorrect, because you have the Red (Out) and White (GND) going to GND, while the Blue (GND) goes to io7.in. Swap the Blue and Red wires.

Ian

texastanker

This post is deleted!

texastanker

@droftarts Looks like that worked! Thank you so much.

Having trouble now homing Z. Not sure if it is related. I can get it to home Z if I manually deploy the probe with a M401 before I send a G30. But when I try using my homez.g file I get an error because the probe did not deploy. Here is my homez.g file:

G91 ; relative position
G1 Z9 F6000 S2 ; raise z by 9
G90 ; absolute position
G1 X136 Y149 F6000 ; go to first probe point
G30 ; probe the bed using z probe to find Z0
G1 Z15 F5000 ; raise z to 15

What am I missing?

Phaedrux

Is this still your probe definition in your config.g?

M558 P9 C"io7.in" H5 F100 T6000 A5 B1

texastanker

@Phaedrux Yes it is.

Phaedrux

Does the probe do a self test with the pin when the printer is powered on?

M401 and M402 work to deploy and retract the pin, but G30 by itself won't?

Can you please send M122 and M98 P"config.g" in the gcode console in DWC and copy and paste the results here?

texastanker

@Phaedrux Self test works fine.
Both M401 and M402 work
G30 won't deploy the probe by itself.

Here are the results:

M122 and M98 P"config.g"
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.4+1 (2022-11-15 17:36:33) running on Duet 3 MB6HC v1.02 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3S0-7JKDJ-3SN6Q-TSMBA
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 152740
Dynamic ram: 66788 of which 0 recycled
Never used RAM 131144, free system stack 219 words
Tasks: SBC(resourceWait:,0.6%,475) HEAT(notifyWait,0.0%,328) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.0%,333) TMC(notifyWait,6.8%,91) MAIN(running,92.1%,1229) IDLE(ready,0.5%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:33 ago, cause: power up
Last software reset at 2023-08-21 01:01, reason: User, GCodes spinning, available RAM 131144, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 132
MCU temperature: min 30.9, current 39.8, max 39.9
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 8, reads 55705, writes 15 timeouts 0
Driver 1: standstill, SG min 0, mspos 8, reads 55705, writes 15 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 55707, writes 14 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 55707, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 8, reads 55707, writes 14 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 55710, writes 11 timeouts 0
Date/time: 2023-08-21 15:07:55
Slowest loop: 1.19ms; fastest: 0.04ms
=== 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 ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122 A0 n0 d0" 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
=== CAN ===
Messages queued 294, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 167/0/0
Tx timeouts 0,0,166,0,0,126 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 47743/1294
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2ad5c
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.4
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 2
Full transfers per second: 0.94, max time between full transfers: 49607270.0ms, max pin wait times: 65.3ms/9.6ms
Codes per second: 0.17
Maximum length of RX/TX data transfers: 3120/1396

Phaedrux

@texastanker said in Creality CR Touch not triggering:

3.4.4+1 (2022-11-15 17:36:33) running on Duet 3 MB6HC v1.02 or later (SBC mode)

Can you update your firmware by running sudo apt update && sudo apt upgrade on the pi command line terminal?

texastanker

@Phaedrux It's going to be a while. I thought I backed up all my config files. I guess I backed up the wrong ones. I had to reimage my PI because I couldn't SSH to it. Now I am starting all over.

texastanker

@Phaedrux Not sure if it had to do with all the settings being redone or the firmware update but it is working now. Thank you!