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.
everything above 250
mb cant be even sliced by my current luban version. File transfer wifi doesnt work for 200mb filds
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.
Edwin
Thank you. I will try Prusa Slicer and see if it makes a difference. The header and ending scripts I am using originally came from Luban sliced files but I must admit I have not ungraded lately.
In some cases, simplify3d messes the comments up (Switched to a new line in gcode).- Clear the comments works fine.
@xchrisd Thank you for your explanation.
Simplify 3D slicer will generate some commands that Snapmaker machine does not support. Please check the start G-code and the end G-code.
Start G-Code
G28 ;home
G90 ;absolute positioning
G1 X-10 Y-10 F3000
G1 Z0 F1800
G92 E0
G1 E20 F200
G92 E0
End G-Code
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G90 ;absolute positioning
G92 E0
G1 E-1 F300 ;
G28 X0 Y0
M84 ;steppers off
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.
Hi all,
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…
Cheers
Hauke
Yes. I have to say that the 240MB file is too large for Snapmaker Luban.
5" Smart Touchscreen (Android OS, Quad Core A7 CPU @ 1.1GHz)
You can think that Snapmaker Screen is just an application in a smart phone and it cannot process such a large file.
Cheers
Edwin
Hi @Edwin,
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!
To give you an idea what project I ran (so you can understand why it is so large), here’s teh link to Thingiverse: NASA CGI Moon Kit 2019 Moon Lamp by moononournation - Thingiverse
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!
Cheers
Hauke
Thank you for your suggestions.
I have forwarded your thoughts to our software developer, @parachvte . They will estimate the needs and try to improve Snapmaker Luban if they have a plan.
Cheers
Edwin
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.
1 GB is too large to process in Snapmaker Luban. The largest file size is about 300 MB for Snapmaker Luban.
I will submit the request to our software team and ask them to add some error warning in Luban.
Edwin