[solved, faulty SD card] weird behavior
-
I uploaded a gcode file, first trough curl, then I assumed curl must messed something up so deleted on the duet and uploaded trough DWC. Same issue again.
Downloaded file from DWC and it is binary. Looks like it's reading from the FAT table directly ?!
I deleted again file from duet, renamed original file to TRTMRT.gcode, uploaded not with drag&drop to "upload and start" but clicked on upload gcode files:
same upload speed as with drag & drop. Downloaded file (right click, download) and again binary file?! Downloaded file is same in size as the one I uploaded, only the content is different, very different.
Original file is 53MB, 7zipped is around 9M5, the file I get from duet back is same 53MB but 7zipped is 9kb.
Link to original GCODE: https://mega.nz/#!1yJXWQTS!UmHOr-gmDKacBXn1B75-IO1tFj0D9xzvNdTF9YZiz34
Link to what I got back from Duet: https://mega.nz/#!gvIlSKZI!JmEFOWrfBYwMJXNNUzlO5lDycWEx68WryuNgJ0ngC18So, to reiterate, uploaded 3 times, with 3 different methods (curl, drag & drop on upload & start, click on upload gcodes and selected file from browser), all three times got identical result.
I sent M112 to the board and I got "Emergency stop trying to reconnect"
Maybe the SD card is dead? I'll try replacing in the morning 5am now not really god time for debugging
-
@arhi said in weird behavior, uploaded G-Code looks like binary:
I sent M112 to the board and I got "Emergency stop trying to reconnect"
I think you might have sent M122 instead, which is a reset.
I've never seen anything like the upload behaviour though. What firmware and DWC version?
-
Pulled the card out, pushed into PC, reading the file from the SD on PC gives same binary duet is reading from the card and sending trough download.
Win10 check disk did not report any errors with the SD card. It is some noname 1G card
Restarted the printer, M112 again did the same thing (printer stuck), rebooted again. Copied original gcode file to /gcodes and now I'll let printer print. (tested unmount, mount on windows, file is there and is ok, put the card in printer, let it print, so far it looks like it's printing it)
-
@Phaedrux said in weird behavior, uploaded G-Code looks like binary:
@arhi said in weird behavior, uploaded G-Code looks like binary:
I sent M112 to the board and I got "Emergency stop trying to reconnect"
I think you might have sent M122 instead, which is a reset.
5AM, EVERYTHING is possible I'll retest more carefully in the morning.
I've never seen anything like the upload behaviour though. What firmware and DWC version?
I reproduced the behavior 3 times. Please download the original file and try to upload to your duet2eth and then download back from duet. I'll do more debugging tomorrow (new card, other big files etc.). I'm using firefox but I doubt that's important since I got exactly the same result with CURL
Duet Web Control 2.0.7
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC2 (2020-02-18b1) -
Do you have CRC checking enabled for uploads? If not, please enable it (in the Machine Specific page of DWC) and see whether it reports any errors when you upload that file.
-
@dc42 it was turned on
where to check for errors ?
-
reproduced again, crc is on, note this is not a single flipped byte, the whole file has nothing to do with original.
2/25/2020, 2:17:33 PM M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC2 running on Duet Ethernet 1.02 or later Board ID: 08DGM-9T6BU-FG3S4-6J9FD-3SD6Q-KVRBF Used output buffers: 1 of 24 (15 max) === RTOS === Static ram: 27916 Dynamic ram: 92132 of which 20 recycled Exception stack ram used: 248 Never used ram: 10756 Tasks: NETWORK(ready,644) HEAT(blocked,1224) MAIN(running,1900) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:03:46 ago, cause: power up Last software reset at 2020-02-23 03:31, reason: User, spinning module GCodes, available RAM 10756 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 5.3ms, max retries 0 MCU temperature: min 41.4, current 43.3, max 43.5 Supply voltage: min 24.0, current 24.1, max 24.1, 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-02-25 14:17:33 Cache data hit count 492121850 Slowest loop: 50.75ms; fastest: 0.11ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === 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 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 209.57ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 Interface state 5, link 100Mbps full duplex
anything else I can extract that's useful ?
-
That's pretty bizarre. I wonder if it's a file size issue. Can you try uploading just the first 1MB or so of the file and see if that works?
-
I just tried another file, that worked a few days ago, it failed the same way (small file 4MB) so I believe this is the SD card issue (it's a noname card, marked 1G but with 2G space, I put it in duet originally just to configure but it stayed inside). I'll replace the SD card and redo the test.
-
Changed SD card, problem gone !!