Exact cause of "File incomplete" messages at print time?  

Re: Exact cause of "File incomplete" messages at print time?

Is it something like the SD card slot having intermittent contact issues? My Mk3 is now starting to have "odd behavior" inserting SD cards so I've printed the reinforcement piece others have used to improve contact reliability.

If file ultralcd.cpp, line 7940
if (!check_file(filename)) {
result = lcd_show_fullscreen_message_yes_no_and_wait_P(_i("File incomplete. Continue anyway?"), false, false);////MSG_FILE_INCOMPLETE c=20 r=2
lcd_update_enable(true);

static bool check_file(const char* filename) {
if (farm_mode) return true;
bool result = false;
uint32_t filesize;
card.openFile((char*)filename, true);
filesize = card.getFileSize();
if (filesize > END_FILE_SECTION) {
card.setIndex(filesize - END_FILE_SECTION);

}

Re: Exact cause of "File incomplete" messages at print time?

Is it something like the SD card slot having intermittent contact issues? It could be, but if I insert the card with files sliced with IM and Slic3rPE, the one sliced with IM will always show the message, even when the Slic3rPE files do not.

I should mention that the IM sliced files are named with very short names with no unusual characters.

My Mk3 is now starting to have "odd behavior" inserting SD cards so I've printed the reinforcement piece others have used to improve contact reliability.Mine doesn't register sometimes, but pulling it out about 1mm fixes the problem until I remove it next time.

Is there an STL for that shim? I might want to print one out just in case.

Re: Exact cause of "File incomplete" messages at print time?

https://www.thingiverse.com/thing:3345508

A quick look at the code implies the FW checks the actual file size against the #define END_FILE_SECTION. In Variants: END_FILE_SECTION for a Mk3 is set to 20,000. So it looks like there may be cases where the printer is misled that the file is shorter or longer than expected. Not sure what the coder was thinking when they wrote this, but is doesn't seem to have any obvious purpose unless card.index only uses exact 20k blocks or has problems if the last read isn't exactly 20k... but it has me scratching my head. Looks like a defect waiting to happen.

if (filesize > END_FILE_SECTION) {
card.setIndex(filesize - END_FILE_SECTION);

There's also special handling of 8.3 filenames ... and an another case with 20 character names. I didn't look too long, but do your IM names fit either case?

Re: Exact cause of "File incomplete" messages at print time?

How did you first set up your profile for the Prusa in IdeaMaker? One of the things I've read elsewhere is that copying the gcode start and finish commands from a Slic3r PE profile introduces some lines of code that IdeaMaker does not recognize. They are related to temperature settings. Frankly, I know next to nothing about gcode, so I really don't know enough to start modifying gcode instructions in the slicer profiles, so I was hoping to find some help here.

I'm running into the same problems as the OP. The printer gives me a file incomplete error every time I try to print a file sliced with IdeaMaker. It works fine every time with Slic3r PE files, so I know it's not a card issue. I suspect there's something missing in the default gcode that IM appends to the file when it slices it, but as I said, I don't know enough to try to figure it out myself. I'd stick with Slic3r PE as it works quite well, except for the custom supports functionality. IdeaMaker has done a much better job in this one area and I'd like to be able to take advantage of that.

Re: Exact cause of "File incomplete" messages at print time?

How did you first set up your profile for the Prusa in IdeaMaker? One of the things I've read elsewhere is that copying the gcode start and finish commands from a Slic3r PE profile introduces some lines of code that IdeaMaker does not recognize. They are related to temperature settings. Frankly, I know next to nothing about gcode, so I really don't know enough to start modifying gcode instructions in the slicer profiles, so I was hoping to find some help here.

I've compiled a (short) list of the placeholders for various slicers here. The only ones I've been able to find for IdeaMaker are for 1st layer (and entire print) bed and nozzle temps. I've posted my IM startup gcode here and end gcode here. With the exception of changing the placeholder names, it's a pretty straightforward conversion of my Slic3rPE gcode. One unfortunately exception is the lack of any sort of conditional, so some things simply can't be translated. It works well though. I really should add the manual lines to set acceleration and jerk since IM doesn't integrate the hardware settings as cleanly as Slic3rPE or Cura:

; Printer calibration settings
M201 X1000 Y1000 Z1000 E5000 ; sets maximum accelerations, mm/sec^2
M203 X200 Y200 Z12 E120 ; sets maximum feedrates, mm/sec
M204 S1250 T1250 ; sets acceleration (S) and retract acceleration (T)
M205 X8 Y 8Z0.4 E1.5 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

I'm running into the same problems as the OP. The printer gives me a file incomplete error every time I try to print a file sliced with IdeaMaker. It works fine every time with Slic3r PE files, so I know it's not a card issue. I suspect there's something missing in the default gcode that IM appends to the file when it slices it, but as I said, I don't know enough to try to figure it out myself. I'd stick with Slic3r PE as it works quite well, except for the custom supports functionality. IdeaMaker has done a much better job in this one area and I'd like to be able to take advantage of that.
I rather like IM. It is a bit tough to get going with due to lack of documentation, bu they do have some very good ideas I wish other slicers would incorporate. The ability to over-ride pretty much any other setting via a filament profile is very powerful.

I've compared the end gcode produced for IM and it's nearly identical to what I include for Slic3rPE. I'm looking into the possibility that the print line counts or something else varies as was noted here.