Bug: can affect print timing by viewing print job.

[squamby]

I was putting my system through its paces at a relatively high speed. Unrealistic for printing today, but who knows when they might discover a print process that can work at high speed. I was using the Kudo3D Titan 1 (copy) with a very simple and fast lift profile. It seems to print fine if I launch the print and don't ever look at the print job. If I click on the print job, the pi suddenly has some distinct pauses between the movements because it is apparently getting too busy as a web server. Changes in movement would not be too much of a problem, but I also noticed that it changed the exposure time to well beyond the 2 seconds in some slices.

I am connected direct on my home network because wifi is still apparently not ready for the pi3.

LogBundle.zip.pdf

[WesGilster]

Awesome. I really appreciate the testing. I'm not sure I've ever really found the need to gather precise resin exposure statistics. There are a couple of problems here:

1. Since my slicing engine is multithreaded, this causes my logs to become interlaced with other actions that are being performed simultaneously. Long story short, I don't have precise exposure stats. I should have something checked in tomorrow that fixes that.
2. The core problem for "precise" exposure times is going to be in replacing the "sleep()" function. It's an awfully imprecise mechanism to control something that should be "more" precise. If that still doesn't give you the precision we need, we can start to decrease the priority of the web threads when a print starts. That would certainly work, but I'd make it an advanced option for those looking to sacrifice web performance for precise exposure times.
3. Somewhat unrelated: I'm noticing seriously long rendering times towards the end of your print. Would you mind allowing me to borrow your stl model to check into that further?

I'll get those exposure calculations into the dev version as soon as possible, but can you give me any idea of what you were seeing for exposure times above 2 seconds?

[squamby]

It was a model I pulled off the web from the Russian site 3DSLA.ru and I have attached it here. Perhaps this model has too many polygons or something, because it also crashes the 3D print viewer with an "out of memory" error. If it matters, my SD card is 16GB and I only have your software loaded and this one stl file. Since this report yesterday, I have tried a few other test stl files and I cannot reproduce the problem, so this particular file is a troublemaker.

I was also seeing variations with the long exposures when I used James' stock Titan 1 profile. I think the root cause is this file and the fact that it can crash the print viewer.

My only programming experience is with C in PIC microcontrollers, so I doubt I can be of much use other than testing the product. I know in a microcontroller that if I want something to have precise timing, I put that code in the timer interrupt section. But my coding pales in comparison to this stuff.

By the way, I don't know where or how to test any developement versions. Is this something I would load by attaching a keyboard to my pi and typing code in the root terminal to perform an update?

3DSLA_TestModel.STL.pdf

[squamby]

I have not actually printed anything yet. I'm just building a system and testing parts and software. I like the features you have where you can view the print in 3D and take pictures and such, but if you were to ask an end user what is most important, I think print quality would have to take priority over all other bells and whistles of the software. If you find you need to start limiting web server communications during a print, perhaps you could move the 3D viewer to the "printables" tab so the object can be viewed in 3D before committing to a print, and then it is not really needed in the "print jobs" tab.

Here is the error that appears on my screen when the 3D model crashes.

[WesGilster]

Yes print quality is certainly an important factor, which is why you can still print a zip of slices like any other piece of software without having any memory concerns. That style of printing is quite simply showing an image on a projector, which doesn't really put any computational/memory burden on the Raspberry Pi. But our aim is to shorten the slicing workflow required for users which is why we implemented printing of raw STL files with no wait times. The drawback to this approach is that it's a more memory intensive and computationally intensive operation than the typical print process. And now that we allow 3d viewing from the client, which can put even more burden on the Raspberry Pi.

You asked a question about 16G of space on your SD card and that doesn't really have any impact on the heap error you are seeing above. Feel free to upload as many files as you want to Photonic3d until you fill your SD card and that will have no impact on the above "Heap" memory(ignoring virtual memory of course). Heap space is related to a Raspberry Pi 3's RAM which is static at 1GB. Of that amount, Java/Photonic3d is currently using about 1/4 of that amount:

pi@raspberrypi ~/Machines $ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize uintx MaxHeapSize := 226492416 {product} java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)

Up until this point, we haven't really had a need to increase the stock JVM settings. Of course as people start to push the limits, we may need to. A quick look at top shows that I could at least double the heap space available to Photonic3d and go to 512M. That would be a pretty quick script change, but I'd like to hear from James to see how much he can give me from the OS as he's the one tuning that area.

To answer your question about downloading a development version, yes you can pull from the development repo by doing:

cd /opt/cwh ./startdev.sh

Which is short for:

cd /opt/cwh ./start.sh "WesGilster/Creation-Workshop-Host"

It's funny that you mention moving the model viewing to the printables page, because that's exactly what James is doing.

I'll comment when I have a version with better logging enabled.

[squamby]

Actually, I'm not sure the heap error is not related.. I say this because the files I upload are apparently going into the /TMP directory of the pi, so isn't this taking up RAM? I know that if I hard power cycle the pi, the files I have uploaded are gone.

On Sat, Jul 9, 2016 at 11:26 AM, Wes G. notifications@github.com wrote:

Yes print quality is certainly an important factor, which is why you can still print a zip of slices like any other piece of software without having any memory concerns. That style of printing is quite simply showing an image on a projector, which doesn't really put any computational/memory burden on the Raspberry Pi. But our aim is to shorten the slicing workflow required for users which is why we implemented printing of raw STL files with no wait times. The drawback to this approach is that it's a more memory intensive and computationally intensive operation than the typical print process. And now that we allow 3d viewing from the client, which can put even more burden on the Raspberry Pi.

You asked a question about 16G of space on your SD card and that doesn't really have any impact on the heap error you are seeing above. Feel free to upload as many files as you want to Photonic3d until you fill your SD card and that will have no impact on the above "Heap" memory(ignoring virtual memory of course). Heap space is related to a Raspberry Pi 3's RAM which is static at 1GB. Of that amount, Java/Photonic3d is currently using about 1/4 of that amount:

pi@raspberrypi ~/Machines $ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize uintx MaxHeapSize := 226492416 {product} java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)

Up until this point, we haven't really had a need to increase the stock JVM settings. Of course as people start to push the limits, we may need to. A quick look at top shows that I could at least double the heap space available to Photonic3d and go to 512M. That would be a pretty quick script change, but I'd like to hear from James to see how much he can give me from the OS as he's the one tuning that area.

To answer your question about downloading a development version, yes you can pull from the development repo by doing:

cd /opt/cwh ./startdev.sh

Which is short for:

cd /opt/cwh ./start.sh "WesGilster/Creation-Workshop-Host"

It's funny that you mention moving the model viewing to the printables page, because that's exactly what James is doing.

I'll comment when I have a version with better logging enabled.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/area515/Creation-Workshop-Host/issues/238#issuecomment-231539783, or mute the thread https://github.com/notifications/unsubscribe/ATak4YV3HYZP7OyfEWCmeki5eRrD3V9Cks5qT72kgaJpZM4JIIHU .

[WesGilster]

Nope, we don't use any ramdisk mounts. What you are seeing is related to the cleanup of files that are put into the /tmp directory. It was a bad choice to store everyone's upload files in a tmp directory. I'll change that in my dev version as well, not sure why I've never fixed that...

Confirm this for yourself by doing a check of your filesystem and you can confirm how much disk you have under the rootfs (which tmp is a small part of):

pi@raspberrypi ~/Machines $ df
Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs           3666764 2536568    931040  74% /
/dev/root        3666764 2536568    931040  74% /
devtmpfs          437856       0    437856   0% /dev
tmpfs              88432     256     88176   1% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs             176860       0    176860   0% /run/shm
/dev/mmcblk0p1     57288   14736     42552  26% /boot
pi@raspberrypi ~/Machines $

[WesGilster]

Wait a second... I'm not liking what I'm seeing here...

[WesGilster]

I'm not sure I've ever taken a good look at this...

[WesGilster]

I guess we are using ramdisks but that's the OS, not Photonic3d:

pi@raspberrypi / $ mountpoint /tmp
/tmp is not a mountpoint
pi@raspberrypi / $ mountpoint /
/ is a mountpoint
pi@raspberrypi / $

[jmkao]

/tmp on a Raspberry Pi is not mounted on tmpfs. It's just a directory on /. There is a cleanup process somewhere that does the cleanup. Even if it were on tmpfs, it's not really a RAM disk. It's memory mapped storage, which means the OS has the choice to store it either in memory or in the swapfile based on prevailing memory conditions. Generally speaking, this won't really reduce available memory for applications and works "magically".

When I load up that STL file, it looks like the total native memory used is about 300MB when the -Xmx is set to that default value (about 226M), which is about 32% additional memory for non-heap usage (e.g. stack, permgen, code cache).

I looks like with the gpu_mem set to 64M, the net RAM reported available to the OS is 925M. OS usage seems to be about 50M, so that nets us about 875M we could give to Java.

With the overhead, that would mean an -Xmx that could go up to 662M as our absolute limit before probably running into trouble.

Linux runs better if there is some free memory for code buffers and disk caches though. My RPi, when not under memory pressure, seems to like 83M of buffers. Caches are harder to measure because Linux will use as much cache as it can, and then de-allocate cache dynamically as processes require memory, so caches typically grow to fit all available space unless disk demand is low. It seems that an RPi running Photonic3D will consume no more than 200M of cache (showing that disk demand is lower than the available RAM), but would require much less to run properly.

The net is that I think 512M would be okay for the RPi 2 and 3.

[WesGilster]

Ah. Cool thanks for the clarification James. I took 512M in start.sh. Fixed the tmp storage issue. Added logging to highlight efficiency of slice on the fly Added logging to show print exposure times.

New version is DEV009.

[WesGilster]

James got this down to a matter of a few milliseconds in cwh-1.0.0-beta3.