Bad command & Missing characters in Gcode since firmware upgrade

dc42

@HBM-3D said in Bad command & Missing characters in Gcode since firmware upgrade:

Thanx. My files were all too big to compare. I tried 4 different program but they all crashed or simply refused to do it.

Did you try Windows fc /b ? AFAIK it can handle very large files. The output when using /b isn't line oriented, but that might actually make things easier for me.

Cam you confirm that the original and corrupt files have exactly the same length? They should have, because the upload mechanism does a check on the file size at the end.

dc42

@norbs12 said in Bad command & Missing characters in Gcode since firmware upgrade:

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:

I am still hoping that one of you can send me a comparison of the original vs. corrupted files, using Windows fc /b or some similar command. See my reply of 20 September.
diff Orig.gcode Downloaded.gcode
...

Thanks. There is something very odd about those diffs. For example:

> 863364c863364
> < G1 X70.502 Y59.729 E.00274
> ---
> > G1 X70.502 Y59.729 E0.00274

Clearly, a 0 has been dropped here (after the E). In most other instances, one character has again been dropped.

> 863391c863391
> < G1 X57.055 Y6 X4.310 E0.00357
> ---
> > G1 X57.055 Y64.310 E0.00357

But here, " X" appears to have been inserted.

> 908990c908990
> < G1 X1G02.446 Y66.725 E0.00361
> ---
> > G1 X102.446 Y66.725 E0.00361

This time, "G" appears to have been inserted.

> 909193c909193
> < G1 X109.288 YY66.944 E0.00303
> ---
> > G1 X109.288 Y66.944 E0.00303

And here, 'Y' has been inserted.

The fact that both these reports are using Duet Ethernet and not Duet WiFi leads me to believe that this is an issue with the transfer of data by DMA from the Ethernet chip, or just possibly an interaction between DMA to the SD card and DMA from the Ethernet chip..

norbs12

@dc42 I do have another ethernet chip, from a different board, I can swap it out today and try again. It might take me some time to get back to you since usually this only happens when the printer has been active and warmed up.

dc42

PS - please can you try again using Windows fc /b to show the differences. Given that RRF checks the received file size, I have a theory that the DMA from the Ethernet chip is dropping bytes, then inserting extra ones at the end of the block in order to finish the block. A diff using fc /b will make it clear whether or not this is the case.

bot

@HBM-3D said in Bad command & Missing characters in Gcode since firmware upgrade:

Thanx. My files were all too big to compare. I tried 4 different program but they all crashed or simply refused to do it.

Visual Studio Code is my new go-to GCode editor. It has comparing built in and can open massssssssive files.

tekkydave

On Windows I always use Textpad as a great editor. Also has a good visual built-in file compare facility.

norbs12

@dc42 quick question, I noticed that M38 doesn't seem to return the exact sha1 even when files are the same. Is this just a bug or am I misunderstanding something.

(using "shasum <filename>" on a Mac)
a03e3b0b03697fccb2997d3e33140801713830c0
-vs-
(M38 on Duet)
a03e3b0b3697fccb2997d3e33140801713830c0

There is an extra '0' using 'shasum' near the beginning of the checksum. I ran the m38 command twice just to make sure it was not a fluke.

Just to make sure I ran a diff and it found no differences.

dc42

Thanks for pointing this out. It's a bug, zeros are sometimes omitted. The SHA1 function was contributed code which I didn't check thoroughly. Will be fixed in next release.

norbs12

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:
OK I got to testing a different ethernet board. Same issues unfortunately. I was thinking of trying out the secondardy SD card slot on my paneldue. I would have to wire it up, do you think it's worth the effort?

Also is there a way to slow down the communication between the network card and the processor in maybe some test firmware? I'd try this myself if I knew how... Was thinking just cut the speed in half just to see if it fixes anything, then if it works make this somehow accessible through a custom gcode command and allow tuning of it (if that's even possible).

Thanks for pointing this out. It's a bug, zeros are sometimes omitted. The SHA1 function was contributed code which I didn't check thoroughly. Will be fixed in next release.

No worries, it's close enough to get a good idea if it's the same file. Was just using 'grep' to speed up verifying if it matched and it didn't show up but looked like it should have, which is the only reason I noticed it.

T3P3Tony

@T3P3Tony said in Bad command & Missing characters in Gcode since firmware upgrade:

@norbs12 can you confirm this only occurs if you are uploading while printing, this is what @HBM-3D found.

@norbs12 is this only an issue if you upload a file while it is printing? That appeared tto be what @HBM-3D reported

norbs12

@T3P3Tony It does seem to be only while printing though I have not had a chance to confirm that it's not related to temperature of the board. Meaning I have not tried uploading immediately after a long print.

T3P3Tony

@norbs12 ahh ok, if its only during a print thats still an issue but less of an issue!

Vinculum

I tried it right after week-long prints and no issue. Only while the printer is running while uploading I get this situation. Uploading when idle never gives issues.

chrishamm

@HBM-3D Maybe a trivial question but was there a deviation of the file sizes between your original and the uploaded file (in plain bytes)?

kmhudgins

Hi,
I am starting to have the same issue with bad commands. Was this problem every resolved?

norbs12

@kmhudgins said in Bad command & Missing characters in Gcode since firmware upgrade:

Hi,
I am starting to have the same issue with bad commands. Was this problem every resolved?

I ended up just avoiding uploading during a print that seems to have solved the issue for one board. I still have another board somewhere that it happens to all the time no matter if I'm printing or not that I gave up on.

droftarts

Optional CRC checking when uploading was added with RRF 2.04 and DWC 2.0.4, but otherwise there has been little progress on this, as far as I am aware.

@kmhudgins What firmware are you using? Are you uploading while the printer is printing?

Ian

BlueDust

@droftarts

I assume the CRC checking is enabled by default. How do you enable/disable them?
Can you have the Duet2 log the pass CRC codes confirming it is good, and not just the failed ones?

2019-11-04 21:06:28 Error: Uploaded file CRC is different (65e13ff3 vs. expected bcc41d9a)
2019-11-04 21:07:27 Error: Uploaded file CRC is different (9401d30a vs. expected bcc41d9a)
2019-11-04 21:08:17 Error: Uploaded file CRC is different (d7835b84 vs. expected bcc41d9a)

A month or so ago, I remember having trouble uploading files with a pop up saying that the CRC failed.
I don't remember what I did to correct it, but just thought it was my slicer having issues. Happy to know this is actually a "thing" and it wasn't just me.

dc42

@BlueDust said in Bad command & Missing characters in Gcode since firmware upgrade:

I assume the CRC checking is enabled by default. How do you enable/disable them?

It's at the bottom left of the Settings/Machine Specific page of DWC 2.04.

If the CRC errors only occur if you upload while printing, then maybe we need to reduce the SPI transfer speed to the Ethernet module if you upload while a print is active, or else adjust the bus priorities.

norbs12

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:

@BlueDust said in Bad command & Missing characters in Gcode since firmware upgrade:

I assume the CRC checking is enabled by default. How do you enable/disable them?

It's at the bottom left of the Settings/Machine Specific page of DWC 2.04.

If the CRC errors only occur if you upload while printing, then maybe we need to reduce the SPI transfer speed to the Ethernet module if you upload while a print is active, or else adjust the bus priorities.

Would be possible to somehow make the SPI speed user configurable? I've got two boards, one that I just stopped using because of this and another that only works as long as I'm not printing. Would be awesome to recover the other board and use it for something.