Posts made by camcamnz

@Dan1990 via ssh/putty.
There is a typo it is actually /var/log/syslog
I ran the following command and watched the output once whilst testing:
tail -f /var/log/syslog

@Thoma308 In that case, your problem is different to mine, as I already tried all the variations of powering pi & duet

@gloomyandy That was my first thought as well, so I moved the rPi out of the enclosure with the other electronics until it was sorted. It is that cable that came with the Duet ![alt text]

@gloomyandy said in Duet 3 losing connection whilst printing:

/varlog/syslog

Yes, I just started the heater, and instantly saw warnings in that log file, as below

Jan 24 13:17:49 duet3 DuetWebServer[564]: [DoCode] Executing code 'M140 P0 S60'
Jan 24 13:17:49 duet3 DuetWebServer[564]: #033[40m#033[32minfo#033[39m#033[22m#033[49m: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1]
Jan 24 13:17:49 duet3 DuetWebServer[564]: Executing ContentResult with HTTP Response ContentType of text/plain; charset=utf-8
Jan 24 13:17:49 duet3 DuetWebServer[564]: #033[40m#033[32minfo#033[39m#033[22m#033[49m: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
Jan 24 13:17:49 duet3 DuetWebServer[564]: Executed action DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer) in 121.9828ms
Jan 24 13:17:49 duet3 DuetWebServer[564]: #033[40m#033[32minfo#033[39m#033[22m#033[49m: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
Jan 24 13:17:49 duet3 DuetWebServer[564]: Executed endpoint 'DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer)'
Jan 24 13:17:49 duet3 DuetWebServer[564]: #033[40m#033[32minfo#033[39m#033[22m#033[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
Jan 24 13:17:49 duet3 DuetWebServer[564]: Request finished in 124.107ms 200 text/plain; charset=utf-8
Jan 24 13:17:49 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad data response was received (0x00000022)
Jan 24 13:17:49 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad data response was received (0x00000011)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0x000000b2)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0xe20300be, got 0x02635649)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0xe20300be, got 0xabbbd02c)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0xe20300be, got 0x66f47fab)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0x00000074)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Lost connection to Duet (Board is not available (no header))
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [info] Connection to Duet established
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0xfee53e33, got 0x29af8a10)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad data response was received (0x0000002c)
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [warn] Lost connection to Duet (Board is not available (no header))
Jan 24 13:17:50 duet3 DuetControlServer[3086]: [info] Connection to Duet established
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0xffffffe1)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0x0000007a)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Lost connection to Duet (Board is not available (no header))
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0x147bc906, got 0x094245ad)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0x147bc906, got 0xb45e66d9)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [info] Connection to Duet established
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0x00000070)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad data response was received (0xffffff77)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad data response was received (0xffffff77)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Lost connection to Duet (Board is not available (no header))
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [info] Connection to Duet established
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Bad data CRC32 (expected 0xf639780f, got 0x6abe97ec)
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Lost connection to Duet (Board is not available (no header))
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [info] Connection to Duet established
Jan 24 13:17:51 duet3 DuetControlServer[3086]: [warn] Restarting transfer because a bad header response was received (0x000000de)

@Phaedrux I tried with the SD card that came with the Pi (That i had been using previously), and I get exactly the same result

@Phaedrux I am seeing the http drops again today.
Ping is not showing anything, I am continuously getting <1ms over the time, no delays or drops when the HTTP drops occur

@Phaedrux actually, the timeouts have stopped.
I did 2 test prints, the first took an hour, and I had 51 timeouts, the seconds took 90 minutes and I had none.
I have had it running now again for 30 minutes and also none (no drops on the ping either.

When I re-imaged the sd card on the 9th, it seems that the image i downloaded already had the 3.2 release, and I didnt do any further changes to it apart from the config files.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956BA-NA3TN-6J1FL-3SN6N-998YU
Used output buffers: 3 of 40 (23 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 93540 of which 64 recycled
Never used RAM 115440, free system stack 124 words
Tasks: NETWORK(ready,199) ETHERNET(blocked,85) HEAT(blocked,296) CanReceiv(blocked,927) CanSender(blocked,344) CanClock(blocked,349) TMC(blocked,19) MAIN(running,1119) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 00:33:49 ago, cause: power up
Last software reset at 2021-01-09 12:49, reason: User, GCodes spinning, available RAM 147848, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 44.6, current 45.4, max 45.5
Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Driver 0: position 27120, standstill, reads 13736, writes 2 timeouts 0, SG min/max not available
Driver 1: position 26800, standstill, reads 13736, writes 2 timeouts 0, SG min/max not available
Driver 2: position 6040, standstill, reads 13736, writes 2 timeouts 0, SG min/max not available
Driver 3: position 0, standstill, reads 13737, writes 2 timeouts 0, SG min/max not available
Driver 4: position 0, standstill, reads 13738, writes 0 timeouts 0, SG min/max not available
Driver 5: position 0, standstill, reads 13738, writes 0 timeouts 0, SG min/max not available
Date/time: 2021-01-12 20:56:38
Slowest loop: 4.79ms; fastest: 0.06ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 822, completed moves 822, 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 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== 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
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: 2.72ms; fastest: 0.02ms
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: 1 of 8

• Ethernet -
  State: active
  Error counts: 0 0 1 0 0
  Socket states: 5 2 2 2 2 0 0 0
  === Filament sensors ===
  Extruder 0 sensor: ok
  === CAN ===
  Messages queued 3007, send timeouts 6765, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48

@Phaedrux A further update, I have successfully finished a small print, so seems to be working well in standalone mode (apart from the HTTP errors)

@Phaedrux Same SD Card, and same config files (just copied to the correct location and added the M552 command)

@Phaedrux
I have it running in standalone.
I am getting a lot of errors, but now they are HTTP timeouts.
Besides the errors however, all seems to be working properly so far, I got through PID autotune and some other commands successfully (ie heating the bed a few times).
I am going to figure out how to re-mount the duet to try to see if I can get something printed successfully

@Phaedrux I just tried a fresh re-image and updating to the latest version, and still have the same issue.

@Phaedrux said in Duet 3 losing connection whilst printing:

That's contradictory. If you're getting disconnected more often, it's not working fine in all scenarios, now is it?

I meant in all other scenarios, other than when the bed heater is on

Hi All, Any suggestions?

Hi @Phaedrux,
Yes I am using that SD Card, but I already re-flashed it because i noticed it came with the lite version, and I am thinking of adding a touchscreen to the pi later (or a paneldue, havent decided yet)
Powering the pi off the duet works fine in all scenarios, I have just noticed that I get the disconnection messages far more often when powered that way.
I don't have anything else connected to my pi, literally just the duet (And currently USB power)

M122

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-RC2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J1FL-3SN6N-998YU
Used output buffers: 3 of 40 (11 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 63216 of which 24 recycled
Never used RAM 145804, free system stack 200 words
Tasks: Linux(ready,75) HEAT(blocked,296) CanReceiv(blocked,927) CanSender(blocked,371) CanClock(blocked,356) TMC(blocked,53) MAIN(running,1217) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:02:05 ago, cause: power up
Last software reset details not available
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 24.0, current 36.6, max 36.6
Supply voltage: min 24.0, current 24.1, max 24.1, 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: position 0, standstill, reads 52891, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 52893, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 52893, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 52893, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 52893, writes 14 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 52893, writes 14 timeouts 0, SG min/max 0/0
Date/time: 2020-12-31 13:29:39
Slowest loop: 0.45ms; fastest: 0.05ms
=== 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, 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 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== 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.
=== Filament sensors ===
Extruder 0 sensor: ok
=== CAN ===
Messages queued 428, send timeouts 1056, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 3ms ago
RX/TX seq numbers: 3891/3891
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-rc2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 0.03
Maximum length of RX/TX data transfers: 3668/836

Hi,
I have just upgraded my Ender 5 Plus with a Duet 3 MB6HC, connected to an existing raspberry pi 3B+ I had already, and have managed to get everything working and tested successfully, with one exception.

During printing, I get random error messages on DWC, normally "Warning: Lost connection to Duet (Board is not available (no data response))", but sometimes "Warning: Lost connection to Duet (Board is not available (no header))", and very occasionally "Warning: Controller has been reset".

I can test all functions of the printer using manual controls and G-Code successfully, and it seems to be related to the bed heater, as I only recall seeing these messages with the bed heater on.

Initially I was powering the raspberry pi off the Duet supply (which I would like to get back to), I also tried powering Duet from the RP, however the only thing that has improved it is running them off separate supplies. This has reduced the occurrences of these messages but I still cant get through a simple print without eventually getting the "Controller has been reset" messages.

I have also tried moving the RP and as much ribbon cable out of the electronics case to minimize any potential interference there but it didn't help.

I was running the latest build of all software on the stable branch, today i tried the unstable but getting the same results.

Apart from the Duet, all other parts were installed and working previously with no problems until I changed the board (ie bed, power supply etc were all ok)

Here is my config file - config.g
and here is a screenshot of the console showing an example print