Issues with Auto calibration

Veti

are you on firmware 3.2? post the m122

and is that the new beg.g that the configurator created?

wcmartino

@Veti Yes currently running 3.2. The beg.g was created by the configurator.

m112 output

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.2 running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: MDHLF-5296U-D65J0-40KM0-2G03Z-RL674
Used output buffers: 1 of 40 (16 max)
=== RTOS ===
Static ram: 98732
Dynamic ram: 95016 of which 36 recycled
Never used RAM 51432, free system stack 192 words
Tasks: Linux(blocked,120) HEAT(blocked,316) CanReceiv(blocked,947) CanSender(blocked,372) CanClock(blocked,363) TMC(blocked,104) MAIN(running,489) IDLE(ready,20) AIN(blocked,267)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:01:20 ago, cause: power up
Last software reset at 2021-01-12 22:17, reason: User, GCodes spinning, available RAM 51224, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Supply voltage: min 0.0, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 64133, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 11, reads 11547, writes 11, timeouts 0, DMA errors 0
Driver 1: position 64133, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 11, reads 11547, writes 11, timeouts 0, DMA errors 0
Driver 2: position 64133, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 11, reads 11547, writes 11, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 11, reads 11546, writes 11, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 11549, writes 9, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-01-13 06:08:06
Cache data hit count 207678856
Slowest loop: 3.30ms; fastest: 0.10ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, 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 = 0 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "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.
=== CAN ===
Messages queued 653, send timeouts 651, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 4ms ago
RX/TX seq numbers: 2215/2215
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x10eec
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 0.08
Maximum length of RX/TX data transfers: 2952/952

This from a fresh power on. Not sure if that makes any difference.

Thanks again for the assistance.

Veti

it does sound like a wiring problem to me. like a making intermitten contact.

wcmartino

@Veti Agreed. I can get it to trigger consistently. Just fails at the one point during auto calibration.

I have managed to get it to do a complete auto calibration once or twice but that is it.

Carlo

@wcmartino

Not sure it will help
M208 Z0 S1 needs to be Z-0.2 or some negative number as the effector is going negative to measure strain

wcmartino

@Carlo I will give it a shot but I suspect this is not an issue as it does probe the first few point just fine and when it fails it just keeps driving into the bed.

Carlo

@wcmartino

Yeah not sure it respects limits during probing

dc42

@wcmartino said in Issues with Auto calibration:

When running the G32 command it hit the first 6 points with no issues every time. When it moves to the 7th point (P6) the nozzle crashes into the bed ever time, no green light. I changed the sensitivity to 40 and still does not trigger on that one point.

A couple of possibilities:

There may be a bad crimp, which causes one of the connections on the 8-pin connector to be lost when the probe moves to that position.
If the bed is not rigid and securely held down, there may be enough give in the bed at that point not to trigger the effector.

@Carlo said in Issues with Auto calibration:

@wcmartino

Yeah not sure it respects limits during probing

It doesn't respect the bed radius limit during probing, because it's often desirable to probe specific points that are outside the normal print radius.

wcmartino

@dc42 I had double and triple checked the wiring and thought everything to be ok even moved the head around manually and tapped the bed with no issues. I went ahead and secured the wiring harness a little better and wouldn't you know it, was able to complete auto calibration multiple times.

Wiggled the wiring while tapping the bottom and can see that it does in fact seem to be a crimp issue. Just happened to be in the right spot every time I checked it that and the fact that it failed on the exact spot led me to believe it might be something else. Going to re-crimp everything and see what happens. Will update when that is complete.

Thanks!!

Carlo

@dc42 Good to know Thanks

wcmartino

So I pulled harness for the sensor completely out. Stuck pins in the connectors to hook up an ohm meter. Jiggled, pulled, push etc on the cable ends and found there are no issues with the cable.

Plugged it back in same issue as before. I tied up the cable to the bowden tube to ensure nothing is getting pulled and everything seems to be working again. Do not see anything wrong with the solder connection on the effector either. Still not sure where the issue is coming from but definitely a connection issue.

I have another effector coming for another project so I will toss it on the printer in hope to eliminate that as a possibility.

Will update when I have more info.

Thank all!

Veti

what happens if you exclude that specific point from the bed.g?

wcmartino

@Veti I had not done that as I am able to reproduce the issue manually. If I manually moved the head by hand, wiggle the connector I can cause the failure.

By providing more strain relief for the connector it works without any issues.