No console output (sometimes)

[Leav]

Hi,

In trying to write a custom script, I noticed a very aggravating issue: sometimes commands that should result in console output, just... don't.

Examples using M115:

Specifically the macro I'm writing uses "G30 ... S-1" which should result in probe results being echoed, but doesn't always echo the results:

G0 X0 Y0 Z10
G30 P0 X0 Y0 Z-9999
G30 P1 X0 Y0 Z-9999
G30 P2 X0 Y0 Z-9999
G30 P3 X0 Y0 Z-9999
G30 P4 X0 Y0 Z-9999
G30 P5 X0 Y0 Z-9999
G30 P6 X0 Y0 Z-9999
G30 P7 X0 Y0 Z-9999
G30 P8 X0 Y0 Z-9999
G4 S1 				; Wait 1 second before the next command to increase likelyhood of output appearing in console
G30 P9 X0 Y0 Z-9999 S-1

I thought the dwell at the end would help but it didn't.

For help debugging, here's the output of M122 (notice -69dbm wifi signal strength, could that be the issue?)

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9K662-MGPSS-6J1FD-3S46N-TVU6Y
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 93124 of which 48 recycled
Exception stack ram used: 472
Never used ram: 9448
Tasks: NETWORK(ready,368) HEAT(blocked,1224) MAIN(running,1624) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:43:30 ago, cause: software
Last software reset at 2020-10-09 17:52, reason: User, spinning module GCodes, available RAM 9392 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 4
MCU temperature: min 32.9, current 33.2, max 33.3
Supply voltage: min 23.9, current 24.1, max 24.2, 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
Date/time: 2020-10-09 18:36:12
Cache data hit count 4294967295
Slowest loop: 0.60ms; fastest: 0.13ms
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 0.0ms, write time 0.0ms, 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: 23, completed moves: 23, 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: 202.71ms; 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 13
WiFi firmware version 1.23
WiFi MAC address 24:62:ab:15:71:64
WiFi Vcc 3.39, reset reason Unknown
WiFi flash size 4194304, free heap 24048
WiFi IP address 192.168.1.6
WiFi signal strength -69dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0

[Phaedrux]

Is your DWC version also 3.1.1?

-69db is pretty borderline, but should still be ok.

Do you also have a PanelDue?

[Leav]

@Phaedrux
Yes, DWC is 3.1.1

My PanelDue is not installed yet. (how would it help?)

[Phaedrux]

I was curious if the output was showing up reliably on the paneldue console.

[Leav]

Can I test using USB perhaps?

[Phaedrux]

Yes the USB console should show some results.

[Leav]

Removing metal cover acting as a bit of a faraday cage, I got the signal strength up to ~-57dbm, but the intermittent response pattern continued.

Connected through the USB terminal, every command got 100% response rate.

[Phaedrux]

Try re-uploading the 3.1.1 zip file (as is) to the /sys folder.

https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/Duet2and3Firmware-3.1.1.zip

What browser? Might not hurt to clear the cache as well.

[Leav]

I confirmed this happens with both chrome and firefox, after cleaning the cache.
I dove a bit too deep into this and confirmed that the Duet is actually sending the relevant packet using Wireshark (spare a thought for a mechanical engineer learning to use wireshark..)

Going to try the firmware update next, perhaps something is funky with my DWC?

[chrishamm]

@Leav Your Wireshark filter may be misleading. I suspect you have two DWC sessions running on the same computer. RRF (in stand-alone mode) keeps code replies only once per device (IP address) and if you have two sessions open, one session will get the code reply whereas the other one will get an empty one (which causes the code to be logged in green).

[Leav]

@chrishamm Oh man this could definitely be it, I'm not the best at keeping my tabs tidy... and it makes so much sense!

Currently stuck during the firmware update. I don't remember it taking this long... more than 5 minutes already.... I hope I didn't bork something...

[chrishamm]

@Leav If the update failed, you should be able to get it running again using bossa. See https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Fallback_procedure_Num_3

[Leav]

Used fallback procedure 1 and all is good.

And yes, it looks like the issue was that I had multiple tabs open....

Thanks @Phaedrux and @chrishamm