How do you switch between web server snapshot jpg and png modes?

[mtru]

I read in another forum a posting by "NathanK" stating:

"The snapshot feature of the web server can generate images either as png or jpg. In LabVIEW 8.6 and later, the default which is generated by the web publishing tool is the png format. In this mode everything happens in memory so there is no snapshot image file generated.

In the jpg mode there is a temporary file, however it is not always the same file and the file is deleted after it is uploaded to the client. I would not recommend trying to use this programmatically.

If you need more control over a snapshot of a front panel (and you are using 8.6), I would recommend making a custom web service that takes a picture of a VI's front panel and returns it to the client. Then you would have control over the image."

I am currently using the web publishing tool snapshot feature with an EXE program written in LV8.6.  However, each time a browser accesses the html file, the EXE file's memory grows by 72KB (this happens with my custom EXE program and with LabVIEW.exe when running the VI in development mode).  I'm assuming this is the png that is generated each time a snapshot is taken, but the program never de-allocated the memory and the program eventually crashes.  I'm aslo assuming that if I switch to "JPG mode", the web server will generate a temporary file and eventually delete it, elminating the memory leak.  The problem is, I don't know how to change the modes from png (default) to jpg.

[RavensFan]

I don't know anything about jpg vs. png mode.  You might want to post a link to the thread by NathanK that you are talking about.

But there is another thread that came up today mentioning a memory leak in the webserver you may want to view.

[nathand]

You can switch between JPEG and PNG simply by adding "&type=png" or "&type=jpeg" to the end of the URL.  See here.

[Anna_K.]

Hello mtru,

Did that solve your issue?

[mtru]

The program is currently in use for testing and I have to shut down and restart the program every few days in between test runs. The next run is scheduled to complete late this afternoon so I hope to be able to test out this solution then. I will post the results as soon as I am able to implement. Thanks!

[mtru]

I attempted to impliment the solution of adding "&type=png" or "&type=jpeg" to the end of the URL.  Neither of these solutions fixed the memory leak issue I have.  However, while I was experimenting with the URL, I had minimized the front panel of the EXE program I was referencing using the .snap function and found out that the memory reallocated back to the OS while the front panel was minimized!  The URL no longer showed the front panel properly, but when I standardized (opened) the front panel back up, the memory was back to normal and started rising again as the URL linked to it.  I decided I could have the EXE programmatically minimize and standardize again every so often to reallocate memory and that appears to be working so far.  If I have any further issues with the memory leak using this solution I will post it here.

[mtru]

This is a follow up on my work-around for the memory leak of the .snap function.  I made my last posting after testing this on my PC.  When I deployed it, it worked fine at first, but over a short period of time, (just over one day), the minimizing of the window programmatically no longer worked correctly.  I had to MANUALLY minimize the window to deallocated the memory.  Then, after another couple days I started getting the error "Running low on virtual memory" from the PC...I found out that the memory being de-allcocated, even when manually minimizing the window, was not going back to the OS, it was just lost all together!  I apologize for posting the information before without completing some more in-depth testing.  I'm still working out a solution and will keep you posted on this thread.

[mtru]

The lastest workaround that I tried was re-writing my program in LabVIEW 7.1 (which does not have the known memory leak issues with the Web Publishing as identified by Known Issue #156479).  This corrected the memory leak but then I had a new problem with the system crashing after running for about an hour.  Instead of trying to figure out this problem as well, I decided to go back to LabVIEW 8.6 and implement another work-around that I thought of over the weekend.  I will make a daemon program that will monitor my web monitoring program.  I will then have my web monitoring program self-terminate once every 24 hours to clear the memory leak.  The daemon program will then restart my web monitoring program automatically.  This work-around is not ideal but is the best option I believe I have until NI can fix this known issue.

[jareds]

Hi mtru, 

A potential workaround to the known issue that you were mentioning is to use embedded mode instead of monitor in the Web Publishing Tool.  Have you tried something like this yet?  Or were you using embedded to begin with?

[mtru]

I am and have been using the .snap function on many applications since LabVIEW 6.1.  It's very simple, easy to use, does exactly what I want it to do, and is still in the documentation of LabVIEW 8.6, 2009 and 2009 SP1 as being supported. 

If I am not mistaken, don't you need to have the LabVIEW runtime engine on the target system to use embedded mode?  I don't want to have to try and keep everybody who wants to see a screenshot of my program to have to have a run-time engine installed.  For one reason, I don't know everybody who wants to monitor our system and they literally can be anywhere in the world if the VPN to our network.  Second, those who I do know would would have me install it for them.  Third, why go "backwards" in capability...everybody would ask me "Why do we have to do this now?..we never had to do it before", and I don't want to use my time/energy at work to explain why NI cannot fix a memory leak that has been identified in at least the last 3 versions of LabVIEW and is still not fixed. 

I had been using either LV 6.1 or 7.1 for a good part of 10 years and had very few problems with them (BTW, DAQmx is the greatest thing every put on a computer EVER).  I finally make the transitioin and start using LV 8.6 on a major test platform last year, got to the very end of it and find this out.  <sigh!>

It is funny (maybe not), but my work around feels like I just changed the floormats in my Toyota car to keep it from "crashing".

However, if I am mistaken and you do NOT need to use LV runtime engine for embedded mode, ignore everything I wrote above and please let me know that this is the case and I will look into it.