Curious. I was trying to print the popular moon lamp on my A350, the 8 inch size. The file size was 329 MB, similar to yours, and also got stuck at 85% parsing loading of the USB stick. I tried going through WiFi to no success, and the gcode wouldn’t load to the workspace in Luban so I couldn’t try direct with the USB to the laptop.
So to print my model I boosted the step height from 0.2 to 0.25, reducing the file size to 264 MB, which did work through the USB stick.
I tried to print a 7.5 mb file sliced in Simplify 3D from USB and it stopped loading at about 60% with a message it disconnect from machine - did I want to reconnect? I clicked the reconnect and the machine froze completely. Then I scaled the model to get about a a 4.9 mb file which also stopped loading but I was able to reconnect. Finally reduced the size to 3.1mb and it loaded fine and printed fine. This was on a 250 with the latest firmware (V1.11.4).
Some similar cases were reported that the files, which are generated from Simplify 3D, will cause some problems to the machine. The controller fails to parse the G-code file due to various reasons. You need to pay attention to the header codes and the ending codes of the G-code file.
That is a software bug that needs fixing. Unknown commands are supposed to be ignored, including comments. They currently are causing something to break, which is not the intended behavior.
There should be nothing you can put in the file that would prevent a successful print, the controllers should be robust enough to discard any unknown commands.
The upstream Marlin firmware does this. At some point the touchscreen addition introduced these quirks, I would gander.
Please make sure the developers are working on fixing this as constantly instructing new users to scan through gcode files and remove known incompatible lines is not ideal. This has implications across 3DP, laser, and CNC gcode files.
just wanted to add +1 here: A huge gcode file (240 MB - highly detailed moon lamp), sliced with Cura, sent via WiFi, Firmware 1.12 → need to start printing after disconnect via “Files”, takes more than a minute to parse for the preview. At ~85% of parsing, a minute gone, I get the “Lost connection” warning. Reconnect works, but message appears again. Still, at the end printing job just started fine - it’s currently running, so cannot tell if there will be late effects, but I suppose not.
Looks a bit like the parsing process eats up all CPU and the watchdog process times out. Perhaps you need to change the job priorities or the “allow to run in background” settings in Android for the watchdog? Just guessing…
I can understand that processing such a large file is hard work and takes a while on such a device, fully understood! But in the end, 240 MB should be well possible with such a processor. The link you provided gives the Raspberry Pi as an example, and that certainly is capable of handling such files. And, after all, the print went through just fine, so I suppose it is really only a timing issue we observe here.
If you say Luban: I’m confused here, since Luban runs on a full-blown PC, and is (or only was?) a fork of Cura, so if I can handle it in Cura, Luban should be able to too, I’d suppose. I used Luban only to transfer the file via WiFi, which worked with no issues.
But I guess my main point would be: A printer of the size of the A350 invites for large prints, and large prints will often mean large GCode files. So I sincerely hope that the device will be well able to handle such large prints!
All in all, I’m positive that the Touchscreen will not be a limitation. And if so, well, then I’ll use a Raspberry Pi with OctoPrint, that certainly will work, and the A350 just receives everything in small chunks via serial interface.
Btw.: The absolutely coolest thing would be if we could have OctoPrint running on the touchscreen - would blow peoples minds!
So based on this thread a gcode file of 1GB is a no go… Can’t send via wifi, I can slice it in Luban 3.15.1 (but no preview or load to workspace is offered) and exporting via cura to USB results in machine crashing while parsing the file.
If the control tablet can’t handle large detailed files then at the very least Luban needs too and needs the ability to upload “chunks” to the control tablet via wifi or usb to allow large seamless prints in a single go.