Posts made by AlecSanchez

Hi guys, I'm having an issue with my MB 6HC apparently losing network connection and stopping mid print. Attached is an m122 report. Also note that the rpi is connected to ethernet and not wifi. Any help would be greatly appreciated!

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0 (2022-03-15 18:57:24) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJMSS-6JTDA-3SS6J-1BG7B
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 67860 of which 0 recycled
Never used RAM 127252, free system stack 154 words
Tasks: ACCEL(notifyWait,0.0%,234) SBC(resourceWait:,71.6%,466) HEAT(notifyWait,2.5%,321) Move(notifyWait,11.9%,248) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,356) CanClock(delaying,1.2%,333) TMC(notifyWait,50.3%,58) MAIN(running,86.0%,1231) IDLE(ready,0.1%,30), total 223.7%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 168:18:44 ago, cause: software
Last software reset at 2023-07-06 10:53, reason: User, GCodes spinning, available RAM 127204, slot 2
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 815
MCU temperature: min 28.0, current 30.8, max 35.2
Supply voltage: min 24.0, current 24.2, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/96/96, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 808, reads 8175, writes 119 timeouts 0
Driver 1: standstill, SG min 0, mspos 984, reads 8211, writes 83 timeouts 0
Driver 2: standstill, SG min 0, mspos 104, reads 8263, writes 31 timeouts 0
Driver 3: standstill, SG min 0, mspos 488, reads 8235, writes 59 timeouts 0
Driver 4: standstill, SG min 0, mspos 488, reads 8235, writes 59 timeouts 0
Driver 5: standstill, SG min 0, mspos 488, reads 8235, writes 59 timeouts 0
Date/time: 2023-07-13 11:11:49
Slowest loop: 403.80ms; fastest: 0.03ms
=== 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 71, maxWait 519395576ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 582890, completed 582890, hiccups 0, stepErrors 0, LaErrors 0, Underruns [1267, 0, 8], 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
Heater 1 is on, I-accum = 0.5
=== 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 5453296, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 3029625/0/0
Tx timeouts 0,0,3029624,0,0,2423670 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 2, checksum errors: 239
RX/TX seq numbers: 26018/26018
SPI underruns 263, overruns 0
State: 5, disconnects: 4, timeouts: 4, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 14082
Full transfers per second: 39.47, max time between full transfers: 194.2ms, max pin wait times: 63.4ms/9.9ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 3160/44

@dc42 This was taken while the part cooling fan and extruder cooling fan were on during a print. It is interesting though that I don't see any improvements from input shaping until about the 150Hz to 200Hz range. Anything higher than that, ringing appears to be re-introduced

@gloomyandy Yes I understand the Z-axis reading due to gravity. But ah that makes sense regarding it not being mounted completely level, thanks for that. I took a reading during a print and it looks like this:

So in the X and Y axes i'm getting a resonance of roughly 176Hz. Is that a typically high frequency?

I have the LIS3DSH hooked up and am able to take readings. However if I take a measurement while the extruder is stationary, it still shows that the extruder is accelerating according to the graph. This is what the graph looks like if I take a measurement without moving the extruder

Am I interpreting this correctly?

@infiniteloop @Phaedrux Just a follow-up regarding this issue. The 3.3v pin on the duet connector has been working great, but with two small nuances:

• The bltouch red light is constantly blinking as if its in alarm mode, although it functions as normal

• the bltouch does not retract when triggered anymore. I had to add an m402 command in all moves that require probing. It is nice when it is doing a mesh bed leveling though as it is not constantly deploying and retracting

@infiniteloop I changed the output voltage to the bltouch to 3.3v and it fixed the problem. No more interference from the y endstop

This is how I wire all of my X and Y endstops, and it was not a problem until I updated to 3.4

@infiniteloop Well I have both X and Y endstops wired as NC endstops

@infiniteloop Sorry I made a mistake yesterday regarding the caret (^)

M574 Y2 S1 P"io1.in"

is reading 0v while inactive, 3.3v while active

M574 Y2 S1 P"^io1.in"

is reading 0v while inactive, 2.97v while active

The switch is connected by two wires to GND and io.1in as shown in this picture:

@infiniteloop @Phaedrux Are there any other io pins I can use for endstops on the board that aren't the 8 IO_X pins?

@infiniteloop This appeared to pull the signal high when the endstop wasn't activated. So no luck

@infiniteloop I would find this plausible, except for the fact that the bltouch deploys properly before activating the Y endstop. This suggests it is wired correctly, right?

I think it is odd that this phenomenon occurs with any switch that is directed to the Y endstop in config.g. It seems that is the more likely issue

@Phaedrux If I can avoid converting to standalone mode that would be great... but if that is a better move forward to test, I can do that. This just very much feels like a possible bug since it occurred immediately after updating

@infiniteloop Those are all correct

Also to confirm, the bltouch works regularly WHILE activated.

@infiniteloop Yea I can see how that can be confusing, let me see if i can clarify:

• If I home x and y, and then home z, the bltouch does not deploy. BUT, while the bed is moving up to home z, if I press the y endstop manually with my hand, the bltouch will deploy.
• the bltouch will deploy at any point along the build area UNTIL I manually activate the y endstop. once i press the y endstop, I am no longer able to use m401/402.
• If i switch the pinouts in config.g to use the physical x endstop as the y endstop, and activate the x endstop, the bltouch no longer deploys

@infiniteloop I have performed these additional steps to give more insight:

• switched the x and y endstop pins in the config.g file (so now hardware-wise, the x endstop acts as the y endstop.)
• activating the x endstop displayed the same behavior - the bltouch no longer deployed
• activating the y endstop did not affect the bltouch

This shows that it is not an issue with the wires shorting. Whichever endstop is allocated as the y endstop in the config.g file seems to mess with the bltouch.

@infiniteloop it is powered by a 24v mean well power supply. The raspberry pi 3b is connected via ribbon cable, and that has its own 5v power supply

@infiniteloop x and y home normally, and duet web control indicates them as homed also. If I send g92 y0 to "home" y, the bltouch works normally. It is only when the y endstop is triggered that something seems to short out

Just a normal microswitch