Error: Bad Command 3954

  • Here's my issue.

    Sometimes, and I haven't been able to determine for what reason, I'll upload gcode and it refuses to run. It will pretend like it's running, but the status bar will go extremely quickly (like it'll "finish" the "print" in like 10 minutes on a 10 hour print). But nothing will ever actually happen. The printer will just sit there.
    I have occasionally been able to solve this by renaming the file to something like a single character. Other times I have been able to solve it by not uploading it to a folder and just to the main directory.
    This particular file I have not been able to solve (despite actually being identical to another file, just at a different temperature).
    I finally noticed that I could tell beforehand whether the file would print or not. The metadata for the file isn't being read by the Duet when this happens. Most of the fields read n/ametadata not read.PNG

    After re-uploading, power-cycling, renaming, re-slicing, etc. for kicks I decided to run the Simulation of the file, to see if maybe that would somehow fix it. The simulation also started extremely quickly, with no layer time estimation info, no coordinates changing as in normal simulation. Basically, it behaved exactly how trying to print the file would behave. Pretends to do it, but doesn't.
    Then a few minutes into the simulation, I got an error. Error: Bad Command 3954
    bad command.PNG
    After this error, normal simulation began, with layer times and the amount of time it was taking was now appropriate.
    I haven't seen anyone reference anything similar. I looked at line 3954 in the code (and the surrounding ones). There's nothing interesting there. it's just extrude moves.

    Once the simulation ended, the print time estimate was filled in, but the file still doesn't work and the rest of the fields are still n/a. And when I went to a different folder and came back later, the Simulation time was n/a again (which isn't normal).

    Again, this file is literally identical to another file which works fine, except the temp is 230 instead of 205. But it happens to some files, seemingly randomly.

    Duet Maestro, Firmware 2.05.1 (2020-02-09b1), Web 2.0.7
    However I've had this (or similar on the surface) problem on multiple firmware versions (last time I mentioned something I was running 2.02b and someone recommended I update). And on multiple Maestros (I own 4).


    Ok, I was just playing around before posting trying to get the file to work and noticing that some other files were also listed n/a, despite having no issues printing them when I first uploaded them. This reminded me that sometimes I would print a file the first time after uploading with no issue, but then when I go to re-print, I run into this problem.
    Anyway, while messing with this I uploaded the current file into the main directory, and everything shows up fine, and I can print it fine.

    But if I drag it into the Production folder (all others don't exhibit this behavior), the info fields go to n/a again. But now I can print it fine 😕

    After doing an E-stop, it doesn't know how tall the file is, but all the other fields are now filled in and it will print.
    I deleted the file, re-uploaded directly into the Production folder again, and all fields show up and it starts printing fine.
    I think it's haunted. At least I sort of understand how to work around it consistently now instead of messing with renaming. But it's still incredibly annoying.

  • bad sd card?

  • administrators

    I assume you are uploading files to the SD card via DWC and then printing them from the SD card. Do you have CRC checking of uploaded files enabled in DWC?

  • administrators

    try searching the file for the string "3954" it may be somewhere else

    Also try downloading the file from the duet and then searching for that string/compare the two files.

  • Moderator

    I would try a fresh SD card.

Log in to reply