John Lokanis

Here is something that has bugged me for awhile: If I open a project and then open a VI that has a lot of sub-vis, it takes a very long time to open (many minutes). I can see the 'VI loading' dialog and it is iterating through the sub-vis at a rate of about 1 VI per second. Once the VI finally loads, I can close it and then reopen it and it opens in about 2 seconds. So, at first I thought it was cached on the second load and that is why it was fast. But, if I close the project and then reopen it, then load a simple VI with very few sub-VIs first, that VI will open fairly quickly. If I then try to open my big VI, it will also open quickly (in seconds). In fact, it opens so fast that I never see the 'VI loading' dialog at all. So, does anyone know what is going on here? This only happens if I load the VIs from a project. If I load them directly they open instantly. -John

QUOTE (Aristos Queue @ Mar 12 2009, 12:24 PM) Yes, but if the app is continuously launching reentrant VIs dynamically, then every time it does this, it needs to allocate space for that VI and all it's sub-vis 'on the fly'. So, there is continuous memory allocation going on in this case.

QUOTE (Mark Yedinak @ Mar 12 2009, 11:04 AM) Those are all good ideas for rearchitecting my system but it would be a lot of work at this point. Currently, my top level VI spawns sub-vis (engines) that run tests on a DUT. My top level VI can display the FP of any of these running engines inside a sub-panel on the main VI's FP. From this sub-panel, I can interact with the UI of the engine. The problem is I cannot use this technique if the engine is running in a different app instance. So, I would have to use your techniques above and separate my engine code into a UI component (running in the app instance of the main VI) and a functional component, running on a different machine (and app instance). Also, I would need to maintain a pool of machines (like a server farm) and be able to ping them for their current load so I can load balance tests across them. A very interesting project, but first I would need to get my boss's approval to spend a few months on it. In the short run, buying a faster machine is easier. I will be sure to post some benchmarks on the Nehalem machine vs the Penryn machine when I get it.

QUOTE (mesmith @ Mar 12 2009, 09:38 AM) Great link! Thanks! I have considered load balancing my test system across multiple machines but it does make it a nightmare to do UI interaction. LabVIEW just does not offer an easy way to embed UIs from other machines. If only I could have a VI in a sub panel that was actually running on a different computer over the network! But, for now, I will be looking at a Nehalem based system to get me over the hump. It is supposed to address the memory access and multicore bottlenecks and yield at least 30% improvement over Penryn based cores. -John

Found some really interesting behaviors when trying out shared clone mode vs preallocate clone mode: I have a massively parallel application that does a lot of dynamic VI execution in many (200+) threads. I have been trying to figure out if I should set all my reentrant VIs (almost everything is reentrant) to the 'shared' mode or the 'preallocate' mode. I am running this app on an 8 core machine. In 'shared' mode, the CPU load on all cores seems to be fairly balanced but the whole system bogs down as I cross the ~100 thread level. Here is what the CPU load looks like: In 'preallocate' mode, the CPU load on one core seems to get 'pegged' a lot but the overall load seems lower. I can reach the ~150 thread level before it bogs down too much and can get to ~200 threads, albeit slowly. Here is what the CPU load looks like in this mode: From talking with some sources at NI, it seems that the UI thread is used for the memory manager as well as all VI server calls. So, in preallocate mode, there is a lot more memory management going on (allocating space for all those clones) and that is swamping out the core that is running the UI thread and the VI server calls, thus causing the sluggishness. In shared clone mode, this does not happen, but the system has to do a lot more overhead (spread across all cores) to manage the shared clones and their execution data spaces. Does anyone have any ideas on what the optimal solution/configuration would be in cases like this? Any 'best practices' to apply here? It seems to me if we are going to be doing a lot of multi-core programming in the future, LabVIEW needs to be tweaked to spread the load out a bit more effectively. -John

QUOTE (Kal @ Mar 5 2009, 05:32 AM) I would first test it with the 'echo' service built into the web server. If that does not work, then you have some sort of networking issue. Call your IT guys. There might be a hardware firewall in the path between your server and client. If the echo test does work, then I would investigate the VI server ports on the EXE running on your server target. You need to have the EXE's ini file set to enable VI Server on the default port if you want to grab the front panel of a VI. To grab a screenshot, the screen must be rendered (someone must be logged in and looking at the screen). And the screensaver cannot be running. Another thing to look at is the Distributed System Manager on the server machine. This will let you peek at the status of your web server to see if it is running. Call NI for support on this tool. It should have been installed with the RTE files. Hope this helps. Good luck. I will try to get around to posting a new version of this with some enhancements soon. One thing I added was the ability to point to different EXEs on the target server, as long as each of them uses a unique VI Server port. Keep watching this space...

Here is a link to the KB article that resulted from finding this bug: Avoiding the window focus bug

QUOTE (Jim Kring @ Feb 12 2009, 02:03 PM) Unfortunatly this is true. But, I managed to get it to work. Check out this post: http://forums.lavag.org/Screenshot-Web-Service-t13285.html' target="_blank">Screenshot Web Service -John

Not sure if this will help but you can check out my web service project here. Some of the code show how to call into other LV apps from a web service and how to call a web service from within LV. One thing I wonder about is how to enumberate all the LV EXEs running on a target. I don't think the method of finding all open projects would work in that case since these are separate compiled EXEs. Anyway, here is the link: Screenshot Web Service

QUOTE (Ton @ Feb 18 2009, 09:58 AM) Sure, but doesn't it need to pass some sort of review before it can be posted there? I thought this forum was where we posted things that might qualify and then the 'reviewer' can give it their approval before we submit it. What is the proper process for getting someting into the CR? I'm happy to follow it. -John

QUOTE (Jim Kring @ Feb 17 2009, 04:20 PM) Your very welcome. Glad to give something back to the community the has helped me so much over the years!

I have created a project that builds and deploys a web service to a target machine that does not have the LV dev suite installed. I used some information on the NI site and some support from NI people to make this work. The web service not only demonstrates how to do this but also has some useful features: 1. Takes screenshots on demand of target machine. 2. Can get VI panel images of any VI running on the target machine. 3. Shows how to call a LV web service from another LV app. I hope you find this project helpful for learning about LV web services and as a tool for remotely monitoring your applications. (I use this to check the status of my test system from my iPod Touch!) Please let me know if you find any bugs or have any suggestions for improvement. -John Project: Download File:post-2411-1234913566.zip Readme: Download File:post-2411-1234913620.pdf

QUOTE (PaulG. @ Feb 9 2009, 12:00 PM) Sorry. some random noise must have gotten on the line while trying to write the original post. Please see the now fully operational battlest..er..post...

I

QUOTE (Aristos Queue @ Feb 4 2009, 08:12 AM) Yes, I have been working with NI support on this for what seems like a year now. It is unfortunate we were not able to find the root cause in time for the 8.6.1 release. I am just glad they finally have confirmed the exisitance of this bug that has plagued my code for so long. I was beginning to fell like Hurley on Lost. Was I just crazy or was there really something wrong in the LabVIEW libraries? Too bad it couldn't have been called CAR 4815162342. One benefit of this has been to review my entire architecture and change it to no longer share queue references between threads. Instead every queue in a VIT gets namespaced and then every sub thread gets and destroys it's own reference to that queue. This eliminates the need to force destroy a queue to clean things up. -John

QUOTE (jdunham @ Jan 21 2009, 03:45 PM) *$*#@!! Firewall. :headbang: Thanks for the help! :worship: :beer: :beer:

QUOTE (jdunham @ Jan 21 2009, 11:55 AM) Can't telnet in. So, the server does not seem to be running. Here is the contents of the ini file: prefDlgTestData=1234 appFont=""0" 13" dialogFont=""2" 13" systemFont=""1" 13" HideRootWindow=True blinkBG=000000FF DebugServerWaitOnLaunch=TRUE server.tcp.access="+127.0.0.1" WebServer.Enabled=True server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000" server.tcp.enabled=True What am I missing? (BTW: I am running 8.6)

I want to connect to another LV app on a different machine, open a reference to a specific VI in that app (the main GUI) and then use FP.GetImage to get a snap of the front panel. I can't seem to get the right ini settings in my remote app to make this work. Has anyone else done this? If so, what are all the steps nessesary to make this work? Will it work over the network or must the caller and callee app both be on the same machine? Can this work at all? thanks for the help! -John

I am trying to build a new runtime installer for LabVIEW under 8.6. I want to include support for the new web service feature. Looking at the additional installers page in the build installer screen, it is not clear what components are needed. I only want to include the parts that are needed to support this on a deployment machine where EXEs will be running. Here is a partial list of the installers to choose from: LV Web Services NI Distributed System Manager NI LV Web Services Runtime NI LabVIEW Run-Time Engine Web Server NI LabVIEW Web Server The help is no help (as is often the case in LabVIEW) and a search with google and on the NI site have yielded no information. Also, I called the support line and spoke with an apps support engineer and they said they would have to get back to me because they also had no documentation on this. So, LAVA is my last hope. Anyone else sort this out already? thanks, -John

QUOTE (Ton @ Jan 7 2009, 12:42 PM) Sure. I spawn many VIs from a VIT and then inside of each of these VIs I create many queues and pass their refs to many reentrant sub-vis (obviously all VIs must be reentrant or each spawned VI from the VIT will block each other). Then I run these VIs for a long time (days). When one or more of them complete their work and close (even though I clean up all my refs on the way out) sometimes (1 out of 50-100x) the LV garbage collection will "accidentally" destroy one of the queue references in one of the other VIs spawned from the VIT that is still running. I do not know if this is an issue due to the fact that the VI was spawned from a VIT or the fact that the sub-VIs are reentrant, but setting all the reentrant VIs to the shared clone mode exacerbates the problem. This is a confirmed bug by NI support but it is very hard to reproduce so I do not know when it will be fixed. I have been working with NI on this for several months. I have seen it in both 8.5 and 8.5.1, under both the DEV and Runtime environments. I have not tried 8.6 yet. -John

In my case, every hiarchy is dynamically created from the same template, so I still need to pass down the name of the VI created from the template as the 'namespace' so each obtain call can use that to generate the queue/notifier name. A FGV would not work well in this case, but some sort of daemon that opens and maintains the queue's exisitance might work. This would mean I would have to call it to clean up when each hiarchy completed and was closing. This gets complicated if there are many different datatypes for each queue/notifier... Leaving it as is (passing the actual reference) is not an option due to the bug in LV's garbage collection routine. So, untill that is fixed, I need to find a reasonable workaround. -John

Thanks for the feedback. It sounds like the pass by name method might be more robust, if a slight bit slower. Currently, I pass these refs to the sub vis inside a big typedef cluster. So, now I need to change all the data types to strings. As was pointed out in the linked thread above, there are lots of issue with reentrant VIs to worry about. I am alreayd looking at ways to make unique names for these items. The best way so far is to namespace them with the caller's VI Name (clone name). -John

I have a lot of code where I pass the Reference to the top level VI and many Queues, Notifiers, etc down to many sub VIs so they can interact with these elements. I use the VI ref of the top caller to position dialog windows on top of the caller UI. I use queues to pass data between parallel threads in producer/consumer architectures. I also use singel element queues to store 'global' data and status so it can be used in many places. For most of these, I do not name my queues/notifiers but instead create them in the top caller at init time and then pass the ref by wire to the sub vis. When all subvis are done and the top caller is exiting, I clean up all the refs before quitting. Is this a smart way to do this? Another option is to give everything a name and then pass the names to the subvis instead. Then each sub-vi would have to do it's own 'obtain/open/etc' on the name to get the reference and the use it. Each sub-vi would also have to clean up it own copy of the ref before returning. The plus is I would not be copiing the ref value each time I branch a wire and also each sub-vi would have it's own private copy of the ref instead of everyone using the same ref number for the underlying queue/VI/notifier/etc. The minus is I would have to incure the cost of calling all the optain/open and release/close operations in every VI. The reason I am considering this is due to a garbage collection/race condition bug in 8.5.1 that is causing a reference to be destoryed (rarely) when some instances of reentrant clones and copies of templates (VIT) are leaving memory. I'm just wondering what the 'best practices' approach is to passing references and if I am going in the right direction. Thanks for your ideas and opinions... -John

Sorry for not replying sooner. Xmas vacation and all... Yes, I use the trick Brian posted on his blog that allows block transfer of data from the .NET space to the LabVIEW space. This avoids the 'GetRows' issue but required a very small .NET DLL to be written. Yes, the NI toolkit is very slow, due to their use of the ADO.NET interface and the aforementioned iteration issue. Most of my communication is via SQL API calls (Stored Procedures). These SPs agregate many SQL statements and other logic on the server to provide the data I request (or insert the data I provide). We have a whole department writting these SP and setting up the SQL server database, with all the indexes, relational design constructs, keys, etc... I try to leave them alone as long as I have a SP for everything I need to do. I do not use ADO.NET, I use SQL.NET. This is like a special version of ADO.NET just for SQL server. It is part of the 2.0 Framework. For this application, I am only interfacing to MS SQL Server and likely this will never change. I keep the connection open all the time until it times out or is dropped due to some issue. In that case, I close it, log the error, wait, reopen and then try again. I have ~30 open connections on each machine (multi threaded app) and I have 14 machines running all the time. So, I have a potential max of ~420 active calls to the database at any given time. Usually this is much lower since all the threads are async and not reading/writting at the same time. I guess my concern is still in the overhead of the LabVIEW -> .NET interface. As was stated, this appears to have been ignored since Brian's departure. I am not up to the task of writting my own C interface at this time. So, it sounds like the only option is to try out the LabSQL interface and see if it is faster that what we have now. If not, then I will have to live with my current performance. thanks for all the ideas. -John

Learn something new every time I read LAVA. I set my default to a local driver (Microsoft XPS) since I never print from the dev env in LV. Now the dialog open in a second instead of 10-20 seconds. Who says olds dogs can't learn new tricks. Now if only that info was in the LV help somewhere, not that anyone can find anything in there...