-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test sending big files (>4MB) to Ultimaker #3
Comments
Print 1 (0.10.10-c)I tested a very large print on the Ultimaker 2, but stopped it halfway because it was to big. The free memory dropped 2 times below the magic barrier. Included are the logs. Firmware version: 0.10.10-c Also after stopping the print navigating away from the page will still result in this message being shown: |
On the Chrome crash. This didn't happen the second attempt? It crashed at what moment? While drawing, starting sending, during sending etc? |
It crashed after i pressed print. Before that drawing was very sluggish. Tested on both my laptop (8gb ram) and the shuttle (4gb) |
Ah, and as long as the number of lines didn't go above 3145728 (the max buffer (in kb)) it cashes (when pressing print)? |
It crashed at around 1200000 lines so if 1 line of code is around 40 bytes (characters) it would be at 48000000 bytes or ~45MB |
Print 2 (0.10.10-c)2nd print on the ultimaker was succesfull it dropped to 1940 somewhere at the start. Dont know why. |
What should be taken into account while looking at free memory is that log rotation may kick in with 2 minute intervals. This leads to a brief time of less free memory (and increased CPU usage) due to copying and compressing the log file. |
Print 3 from tablet (0.10.10-c)During my print from my Nexus 9 the ultimaker started making strange noises and hanged on 1 location so @mesut-pehlivan powered it off. I hope this is a printer issue. Can we check this in the logs? |
@olijf Could we try this once more, since the first print was manually interrupted? |
Print 4 from tablet (0.10.10-c)Again same effect. |
It looks like the wifibox disconnects while the tablet is sending gcode en then the wifibox reconnects but the sending of gcode is never resumed, so the wifibox eventually runs out of gcode to print en then just stops. |
@olijf is right: Doodle3D/doodle3d-client#304 Let's do a extra test from a computer with a WiFi-Box connected through ethernet cable, to see if there are other issues. |
Print 5 from PC (0.10.10-c)Printer ran out of gcode to print. Does not look like it is the same issue. It is possible that this was an error because I did not refresh my browser correctly.
|
Print 6 from PC using ethernet (0.10.10-c)Print failed. hanged at 71% I do not understand why as the ultimaker did have enough buffer to continue. This might be a different issue? |
We've released a new beta version: 0.10.10-d. (Release notes) Let's also check once that:
|
Test from tablet using 0.10.10-dI tested the new fix to see if it helps... unfortunately the print stopped halfway but according to @peteruithoven this is not something related to Doodle3D/doodle3d-client#304 Also after restarting the printer because it hanged I experienced a lot of
errors. seems something is wrong while communicating with the ultimaker. Also print3d does not get started. This seems to be something different... I'll look into it tomorrow. |
Test from tablet 0.10.10-dTested using my tablet.. unsuccessful. |
That is strange as the lines printing that error have been modified to include the specific sequence numbers (here). After checking the js in the image, it seems it still contains old javascript. |
For some reason 0.10.10-d indeed contained old javascript code. We've released 0.10.10-e and this does contain the latest javascript code. Let's try the tests from #3 (comment) again. |
Test from tablet 0.10.10-eTested using my tablet.. unsuccessful. Also it looks as if ram usage is still an issue: the putty log shows that the wifibox drops below 2000KB
|
Test from tablet 0.10.10-eAgain same buffer issue: hangs while waiting for the buffer to drop below 75% |
Test from tablet 0.10.10-e 3Again same buffer issue. |
test from pc 0.10.10-e 1Test successful |
Test from pc 0.10.10-e 2Test succesful |
I looked into why the ultimaker usb did strange things (read error -145 means timeout btw) and according to openwrt this is a known issue with certain usb devices when they draw too much power from the port on atherors hardware. see: https://dev.openwrt.org/ticket/16467 |
Test from galaxy tab tablet 0.10.10-e 1This time I used another tablet to see if the buffer issues would arise. but this test was successful. I am unsure that this has anything to do with the tablet at hand. I did completely reset the wifibox and removed all settings just to have a fresh start. |
Test from galaxy tab tablet 0.10.10-e 2I did another test, this time I didn't enable the heated bed. Shape did not stick very well so I stopped the print. |
@olijf Could you do 2 more of the same tests with your own tablet and adding a usb hub between the WiFi-Box and the 3D printer? (Relevant for Doodle3D/print3d#44) |
Test from nexus 9 tablet 0.10.10-eI tested using a small usb hub and verified that it worked correctly. It might be possible that the usb |
Test from galaxy tab tablet 0.10.10-eI did some more tests on the Galaxy tab. I forgot to upload the logs. If I remember correctly both were successful. Might be useful . |
We've released 0.10.10, so I'm closing this test. |
Remove sketches and settings
).Bulk
.Web console
. Paste the following and press enter.MAX_POINTS_TO_PRINT = Printer.MAX_GCODE_SIZE = 999999999999999999999;
Keep this Web console open.
while true; do echo "$(cat /proc/meminfo | grep MemFree | sed -E 's/^[^0-9]+//') $(date '+%H:%M:%S')"; sleep 10; done
. (This will keep checking the available RAM). Keep this terminal window open while printing. You might want to increase the buffer of your terminal so it can "store" more results.[WiFi-Box ip]/d3dapi/info/status
[WiFi-Box ip]/d3dapi/printer/progress
buffer_size
andmax_buffer_size
values. Thebuffer_size
should increase, but stay undermax_buffer
.buffer_size
is gets very close tomax_buffer_size
), in the browser tab with the Doodle3D client, in the Web console, there should appear a message containingbuffer_full
. When the buffer is full, messages containingPrinter:waitForBufferSpace
should appear. This should appear for about 30 seconds (because it keeps checking the buffer). Then when the buffer is 75% it should continue sending print parts.Download SVG
).Let's try this 3 times, without restarting the WiFi-Box (or the printer). After a first print without issues we can skip steps 7, 9 and 10.
The text was updated successfully, but these errors were encountered: