Don't forget that to the saved transfer times you have to add time to compress and uncompress the file.
BTW: 334 MB is really quite large. Did you set the slicer details to the limits?
The file was actually containing TWO copies of the SONOS bracket.
I do that to print multiple copies of a 3D printed part.
I had a short look:
WiFi 5 GHz usually works with 802.11n. That runs on 600 MBit/sec.
Even if you have bad conditions, you may have effectively 33.4 MByte/sec
That is 334 MBytes divided by 33.4MBytes/sec = 10 seconds.
If you connection is slower, you may check you WiFi settings and/or use a different channel.
I will check tomorrow how long it takes a Raspberry 4b (8Gb ram) to decompress that zipped (61 mb) gcoded file, and let you know the result.
I reckon that the decompression will save time, considered the long transmission time of that 334 Mb gcoded file.......
Laterrr!!
Robbert van Herksen
Istanbul, Turkey
PS:
I just bought a Raspberry Pi 5 (8Gb), and it seems to run twice as fast compared to a Raspberry 4b (8Gb).
That higher CPU speed will give some 100% timesaving number-crunching
1 Like
The transmission itself shouldn't take long as @Ewald_Ikemann said
what might take a moment is analyzing that file
I will measure the transmission-time tomorrow... and let you know.
Cura's UFP file format is/was very similar - effectively a zip file, that contained the gcode, and some metadata including a thumbnail. Another @jneilliii masterclass brought us a Cura Thumbnails/UFP plugin - although now it's all consolidated into Slicer Thumbnails with different implementation.
Very possible to create a similar implementation using the plugin API, to allow uploading .zip files.
1 Like