It's out! RepRapFirmware 2.0 and 1.21.1 released

dc42

Thanks, please leave those files available for a while, until I get a chance to try them.

garyd9

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

Thanks, please leave those files available for a while, until I get a chance to try them.

@dc42, here's another one. There's nothing fancy going on with the slicing in this one. It's a simple 0.1mm on all layers, all the same S3D process, etc. The printer config hasn't changed (and those links should still be valid.)

https://drive.google.com/open?id=1k5iV9TFxFvLtPfjYRNsFEFccoK43vVHq

The only thing I see in common with the previous example (other than the fact that firmware 2.0.1 isn't showing a filament or layer time estimate) is that both are large (>64MB) gcode files.

The previous example finished printing just fine. This one is still printing (3h, 42m into the print.)

Take care
Gary

dc42

Thanks. This is on my list to investigate, but right now I'm rather busy getting things ready for the TCT show.

In the GCode Files page, does DWC show an object height and/or the amount of filament required for printing those files?

garyd9

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

Thanks. This is on my list to investigate, but right now I'm rather busy getting things ready for the TCT show.

In the GCode Files page, does DWC show an object height and/or the amount of filament required for printing those files?

I completely understand being busy! The files will sit on my google drive until you've had a chance to do whatever you need.

To answer your question, the "object height" and "filament usage" columns on the "G-Code Files" page show "n/a" for these particular gcode files.

However, the gcode files do print successfully.

dc42

@garyd9 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

To answer your question, the "object height" and "filament usage" columns on the "G-Code Files" page show "n/a" for these particular gcode files.

OK, that explains why the estimates are missing. Now we need to determine why the firmware failed to retrieve the object height and filament usage. Please run M39 and check the SD card cluster size. If it's less than 32K, then using an SD card formatted with 64K clusters (if 8Gb or less) or 32k clusters (if larger than 8Gb) may fix it.

garyd9

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

@garyd9 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

To answer your question, the "object height" and "filament usage" columns on the "G-Code Files" page show "n/a" for these particular gcode files.

OK, that explains why the estimates are missing. Now we need to determine why the firmware failed to retrieve the object height and filament usage. Please run M39 and check the SD card cluster size. If it's less than 32K, then using an SD card formatted with 64K clusters (if 8Gb or less) or 32k clusters (if larger than 8Gb) may fix it.

M39 ->
SD card in slot 0: capacity 15.99Gb, free space 15.50Gb, speed 20.00MBytes/sec, cluster size 8kb

I won't be able to physically get to the machine until this evening (6 hours from now.) I'll open the machine, pull the sdcard and reformat it then. I'll post back the results.

Edit: I'm a bit confused. You stated to use a larger cluster size for a smaller device?

dc42

With 8Gb and smaller SD cards, you can format them using FAT16 format with 64kb clusters. With >8Gb you are forced to use FAT32, which allows 32kb maximum cluster size.

garyd9

Windows 10, 16GB microSD card, FAT32, allows 64KB clusters. I'm formatting it to 32KB just to have a "known good" situation, but wanted to point out the possibility in case you were unaware.

garyd9

After reformatting, copying everything back on the card, I have:

M39
SD card in slot 0: capacity 15.99Gb, free space 15.51Gb, speed 20.00MBytes/sec, cluster size 32kb

However, still no object height or filament usage in the gcode files page. That being said, I'm wondering if the problem is the duet firmware or S3D's export of the gcode file. The reason I'm saying that is because I took a look at the end of the exported gcode file and found the normal "build summary" followed by a newline and then ~26 million NUL characters. (At least I think it's nothing but \x0 characters. I know the first 100 or so are \x0, and the last 100 or so are \x0, and the last one is in column position 26,556,136.)

I'm not familiar with that part of RRF's code, but it seems reasonable that the stats come from seeking to the end of file and rolling back a bit to look for the build summary.... and it also seems reasonable that it wouldn't seek a negative 26 million from SEEK_END. (I'm actually laughing as I type this.)

I'd report this as a bug to S3D, but I found out very soon after I paid them that their technical support is... bad. If I reported this, they'd likely respond that I should use more skirt layers, or clean my nozzle, or something else completely irrelevant.

So, please forgive me for wasting your time, but you can add this to your list of possible causes for the particular problem.

EDIT: Confirmed that the duet shows the proper values after deleting 26 million null characters. I also found this thread on S3D's forum: https://forum.simplify3d.com/viewtopic.php?t=8459

Take care
Gary

dc42

I'm glad you solved it. RRF seeks up to around 150kb back from the end of the file to search for the object height and filament usage.