RRF 2.02, Slic3r PE 1.41.2: Filament used and print times wrong

pkos

Huh. It's the very same (and untouched) SD card I got with the Duet. Weird thing is - files that fail - always fail. File that are good are always good. Would you then recommend I replace the card with something different/faster maybe?

dc42

First use M39 to check the cluster size that the SD card was formatted with. If it isn't 32kb or 64kb then you could save the entire contents, reformat it to 32kb or 64kb, then copy the data back onto it.

pkos

Understood.

I just checked:

M39
SD card in slot 0: capacity 0.50Gb, free space 0.35Gb, speed 15.00MBytes/sec, cluster size 8kb

I'll run a test after this (long) print is finished.

But now this has me curious. I have another board waiting until I'm done building a new printer. Will check later what the cluster is there.

pkos

@dc42 Right. So I replaced the card alltogether and this one I formatted into FAT@64kb cluster size.

Upon first loading the card with the old contents copied over - metadata was still missing.
But after deleting the files and reuploading them - metadata is here.

What bugs me now (and I hope you won't mind explaining this to me) is:

How come the old cluster size made the files load up incorrectly?
The card I bought reaches full 15MBytes/s on a PC and is seen as such by the Duet:

but the highest upload speeds I get to the Duet Maestro is 500 KB/s. Should I look at my network here or is this some other limitation?
Just so I have the full picture - is it normal that the Maestro comes with a 512MB SD card while the bigger Duets have a 4 gig card (I checked on my Duet Wifi - 4gig card formatted in FAT at 64kb cluster size).

And finally - thank you for helping me solve this thing. Now I can happily finish printing parts for my HEVO.

dc42

@pkos said in RRF 2.02, Slic3r PE 1.41.2: Filament used and print times wrong:

How come the old cluster size made the files load up incorrectly?

To avoid DWC timing out, when it is asked for file information, the firmware spends a limited amount of time trying to read it. Reading backwards from the end of the file can be very slow when using a small cluster size. So it may time out before it has found all the information.

The card I bought reaches full 15MBytes/s on a PC and is seen as such by the Duet:

but the highest upload speeds I get to the Duet Maestro is 500 KB/s. Should I look at my network here or is this some other limitation?

If you are running firmware 2.02 (or a 2.03 beta), send M122 P104 to test the SD card write speed without involving the network. When I run that test, I get about 1.2Mbytes/sec. That's using an 8Gb card (so not the original one) formatted to 32kb cluster size. Smaller cluster sizes are generally slower.

If you get much slower figures than that, try a better SD card. The actual speed you get when uploading files over the network depends on both the network throughput and the SD card write speed.

Ideally we'd use a larger RAM buffer to get better SD card write speeds, but the RAM on the Maestro is limited. So we use 8kb buffers. I'm looking at better overlapping network and SD card activity to see if we can improve the transfer rate.

Just so I have the full picture - is it normal that the Maestro comes with a 512MB SD card while the bigger Duets have a 4 gig card (I checked on my Duet Wifi - 4gig card formatted in FAT at 64kb cluster size).

Yes, that's normal. M3D manages the manufacture of the Maestro, and they procure the SD cards for it. Whereas we procure the SD cards for the Duet WiFi/Ethernet.

pkos

OK. I found the problem. It wasn't Duet. It wasn't even Slic3r PE (well... technically)... It was the name of the file in the Hypercube package.

And I screwed up the upload to David.

With Slic3r PE - I use the send to printer function so it uploads directly and starts the print.
When downloading the files to send to David, I misread the fact that the files downloaded from Duet directly were exported incorrectly and I added .gcode at the end of the name.

Now I sliced another part to print out and the problem reappeared.
I exported the file directly to the hard drive this time and was surprised the extension of the file was .0 and not .gcode.

The file I loaded up to print was:
Y_Carriage_Clamp_LM10UU_1.0.stl

Slicer exported the file as:
Y_Carriage_Clamp_LM10UU_1.0

and uploaded with the same name to Duet. All I had to do was rename the file on the Duet for the metadata to load up properly.

So the end question now is - where is the misbehavior- in Slic3r when it exports a file without .gcode at the end? Or in Duet that it reads the file and even manages to print it, but doesn't read the metadata?

pkos

@dc42 Great. Thank you for the explanations and the help.

dc42

@pkos said in RRF 2.02, Slic3r PE 1.41.2: Filament used and print times wrong:

So the end question now is - where is the misbehavior- in Slic3r when it exports a file without .gcode at the end? Or in Duet that it reads the file and even manages to print it, but doesn't read the metadata?

I'm glad you solved it. RepRapFirmware only tries to read metadata from files whose names end in .gcode or .g or another extension that is commonly used for GCode files. So if you use DWC to upload a file without a recognised GCode extension in future, then you can rename it in DWC, appending .gcode to the name. Then press the Refresh button and it should read the metadata.

pkos

Right. I need to check unbranded Slic3r then to see if it will also have that problem and have a go with Prusa guys to get this fixed

Thanks again!

Stephen6309

@pkos In slic3r, check print settings->output options and check the output filename format is what you want. I use PLA_[input_filename_base].gcode, for pla.

pkos

@stephen6309 Thanks!
Weird, I don't think I ever went there to change anything, but yeah - extension was missing in that single profile.

Much appreciated