topic_solved No console output (sometimes)
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
Is your DWC version also 3.1.1?
-69db is pretty borderline, but should still be ok.
Do you also have a PanelDue?
Yes, DWC is 3.1.1
My PanelDue is not installed yet. (how would it help?)
I was curious if the output was showing up reliably on the paneldue console.
Can I test using USB perhaps?
Yes the USB console should show some results.
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.
Try re-uploading the 3.1.1 zip file (as is) to the /sys folder.
What browser? Might not hurt to clear the cache as well.
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?
@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).
@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...
@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