John Lokanis

I have run across a strange issue. I have some code that calls FP driver VIs (from vi.lib). These VIs are loaded dynamically by an EXE (plug-in architecture). I build the library of these VIs for distribution using OpenG (target: llb). I also exclude the vi.lib VIs since these should be included in the RTE. This has worked fine for all my code up until I starting using the FP VIs. (FP Open.vi, FP Read.vi, FP Write.vi, FP Close.vi). It seems like these VIs are missing from the RTE vi.lib. Very weird. Does anyone know how to have the OpenG builder include just some of the VIs from vi.lib that a particular VI has dependencies on? I don't want to include everything from vi.lib in my LLB distribution or it will be huge. thanks for any ideas. -John

QUOTE (jdunham @ Jun 4 2009, 12:36 PM) I think your first problem is the statement above. In the RTE, there is no concept of a 'project' that a namespace is running in. That is strictly for the IDE. Once you build an EXE, the only unique namespace is the name of the application, which is easy to get from a VI Server property. I find that if I want to have multiple instances running at the same time and communicating vi VI Server under the RTE, I need to set up each one with it's own unique port number. And, 'localhost' does not always work either when trying to get a referecne to an app instance from another app. You need to use the actual IP of the machine for this to work reliably. Yes, it is all very confusing. Espcially when you start using Web Services that run in yet another special app instance, separate from your EXE. Good Luck!

One option is to write a web service interface for your application. This can allow any language that can make http requests to script the functionality of your program. It is not quite like the traditional GUI test harnesses used by commercial software test systems but it might solve your need to allow other tools to control your LabVIEW app. If you just want to control the VI through the standard windows hooks into GUI elements, I am not sure if that will work with LabVEW EXEs. But, I have used a tool to do the opposite (control the GUI of a standard windows app from LabVIEW) that might offer some insight. The tool is called AutoIt. http://www.autoitscript.com/autoit3/index.shtml hope that helps. -John

QUOTE (vugie @ Jun 2 2009, 01:28 AM) Slightly off topic, but why would you ever make a VI where you needed to scroll to wire? If the VI is so big that two connected nodes cannot fit on your screen, then it is time to re-factor! Back on topic, I think the whole concept is like trying to compare apples to oranges. There is simply no way to accurately compare a graphical language to a text based one. It's like comparing radio to television, IMHO...

I reported this to NI but am posting here so everyone is aware of this and can avoid losing work. If you have a linked tunnel in your code and try to make a copy by ctrl drag, it will crash LabVIEW. I was setting up a state machine and made a shift register that connected through a case statement with a linked tunnel. I then wanted to make several copies of this setup for passing data around my code. When I selected the shift register, wires and the linked tunnel, then held down ctrl and dragged down to copy, the system crashed. If the tunnel is not linked, then the copy operation works fine. see attached example. Download File:post-2411-1242859218.vi -John

QUOTE (minzuk @ May 19 2009, 01:37 AM) You are welcome!

I have created a new example along the same lines. Instead of fading in, this example overlays a transparent VI on the caller. If the caller does not have an open panel, then it moves up the hierarchy until it finds an open panel and overlays that one. The image is a simple animated gif that spins, showing a time consuming operation is running. I hope this is useful in your UI designs. Download File:post-2411-1241482449.zip -John

Yet another update. Fixed two bugs: 1. The wscleanup.bat file had an error. Debugging code was accidentally left in so it was not doing anything. This new version should fix that. 2. The screenshot function no longer worked now that I changed the server to be run as a windows service. This is because it was not associated with any user who has a screen to render. So, this new version has the web service VI call out to any EXE that the user is running and runs the screen grab code in that user's app instance. The caveat is the user EXE must have the 'get local screenshot.vi' embedded and in memory so it can be used by the web service. I am open to better solutions to this if you have any. Download File:post-2411-1241054615.zip -John

QUOTE (Mariano Gauderio @ Apr 27 2009, 09:12 AM) You do not need to enter the name of the EXE. The exe name is meaningless to the web service. You do need to enter the name of the VI, like you did above: http://localhost/screenshot/get_panel/png/test.vi What error are you getting when you do this? Have you enabled the VI server in the INI file for your EXE? What port did you set it to? Try adding the port number to the end of the call. For example, if your EXE is on port 3363, then call it like this: http://localhost/screenshot/get_panel/png/test.vi/3363 Also, try specifying the actual IP address of the machine instead of using localhost. I have seen some bugs with trying to get the proper application instance reference when only using localhost for the specifier. -John

QUOTE (Mariano Gauderio @ Apr 23 2009, 04:38 AM) As for language issues, I don't know anything about customizing software for non-English versions of windows, so you are on your own. Since you say the echo test is working, that means that the web server is running AND the web service has successfully been deployed. So, that is good. In order for your LabVIEW built EXE to be viewable by the web service, the EXE must have VI server enabled. Also, you need to know what port VI Server is set to. The default it 3363. If you use a different port, then you must specify it in the web service call. Do not use 3364 since that is what the web server is using. Here is an example of the things that must be in your EXE's INI file for the VI server interface to work: server.tcp.enabled=True server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000" server.tcp.access="+127.0.0.1" server.tcp.port=3363 You do not need to specify a path to your VI that you want to get the image of since it is already in memory. You do need to enter it's name correctly, however. Another thing you can try is the screenshot web service call. If that works, you can at least prove you can stream MIME types from you machine to your client. If that is not working, then you have IT issues (firewalls, etc). I can't help much with that either. There is no need to build an LVWS file to use the services I have already created. The project already does that for you. If you want to make more web services for other uses, then you would create your own LVWS and place it in the install directory. Hope this helps. Good luck! -John New version with minor tweaks. You no longer need to stop and start the service when updating. Also, the wscleanup batch file now does this for you when installing your own LVWS files. And I updated the PDF. If I have to type 'web service server service' one more time, I might go insane... -John http://lavag.org/old_files/post-2411-1240533082.zip'>Download File:post-2411-1240533082.zip

One note of caution, I have discovered that if you place a new LVWS in the install folder while the web server is running that it will get deployed BUT it will not run until you stop the web server and then restart it. This is counter to what NI told me. So, use the 'Stop NI Web Service Server' before installing new LVWS files into the install folder and then use the 'Start Web Service Server' to restart the service afterwards. Also be sure to cleanup the old deployments while the server is stopped. -John

Major upgrade! I have changed the project so that it creates a windows service. I have also renamed it to: NI Web Service Server This is more of an 'engine' that keeps the web server running all the time. So, now your other projects do not need to install/run the web server. Instead, all they need to do is place their web service LVWS file into the 'install' directory and the web server will deploy them automatically. I am still including the web service that allows you to take screen shots of your target machines as well as retrieving images from VI panels or your EXEs. This now works with multiple EXEs by allowing you to specify the VI Server port that the EXE is listening on. And I added a new web service that can get the version number of your EXEs. We use these web services on all our deployed machines to be able to do remote support and to query the installations for maintenance tracking. I hope you find this useful. There is a lot of power in the new web services once you sort out the gory details. I hope this example helps show the way. -John Download File:post-2411-1240260082.zip

QUOTE (ned @ Apr 18 2009, 01:27 PM) I will give that a try, but I doubt the 'localhost' string will work since that is the default value if left unwired and when I did that it definitely did not work.

I have spent some time trying to figure this out and here is what I can tell you that might be helpful. 1. Web Service VIs run in a separate application instance from the LV EXE that starts the web server. 2. Web Service VIs 'think' they are the application that started the web server. (have your web service VI return the App.Name property and you will see what I mean). 3. If you want to talk to your EXE (or any EXE) form the web service VI, you must open an app reference to that EXE. If you try to just use the Default App Instance, you will get a reference to the app instance of the EXE that started the web server. If you have multiple EXEs, this can be a problem. If you have one EXE that acts as windows service to keep the web server running, then this fact will prevent you from calling into other EXEs. 4. If you use the Open Application Reference function and leave the machine name input blank (because your web service and your EXE are on the same local machine) then the app reference you will get will be for the app instance that your web service is running in, NOT your EXE, even if you supply a different VI Server port number that is unique to your EXE. It just will never work. I think this is a bug, IMHO. 5. In order to connect to your EXE, you must provide both the actual IP address of your machine and the VI Server port of you EXE. An easy way to get the IP is to wire the output of the 'String to IP' function into the input of the 'IP to String' function, set the use dot notation input to TRUE and do not wire anything into the 'String to IP' function. Wire the output of 'IP to String' into the machine name input on your Open Application Reference function. I hope this saves someone some time. I wasted a day on this. Too bad NI chose not to document any of this...

Good sessions. Thanks for taking the time to come visit us up here and share your wisdom. I am already bugging my boss about putting more time into software quality efforts. Wish he could have attended the session. -John ps. I still want my mouse wheel to work in the string control!

QUOTE (Darren @ Apr 14 2009, 03:32 PM) Thanks for the quick follow up. I guess I'll file that in the 'just don't do that' bin for now...

Here is the setup: You have a VI with at least one horizontal splitter. In each pane you have an object set to fit to pane (scale object with pane). (for example, a multi-column listbox). The user maximizes the screen. They then move the splitter bar that separates the upper and lower panes below the previous (un-maximized) bottom of the window. Finally, they return the window to its previous size (by pressing the un-maximize, or restore button). The result is a totally messed up window. Is there any way to avoid this? See attached VI. Download File:post-2411-1239747456.vi Before: After:

QUOTE (gmart @ Mar 26 2009, 03:20 PM) Yes, but as it turns out this is not working correctly for web services. Here is the response I got from NI: "I just tested this, and the App.Kind property currently reports as being in the Development Environment. I don't believe this is proper behavior, so I reported it to R&D under Corrective Action Request (CAR#) 157042 so they might change it in a future version."

QUOTE (gmart @ Mar 26 2009, 01:46 PM) Yes, but what 'App.Kind' is a web service?

QUOTE (NathanK @ Oct 17 2008, 09:00 AM) I have a question about this. What if you want to write some code that will work in both the case of running under the dev env where you ahve a project open AND running as a compiled EXE, were the main exe is in the main app (default) instance. Can you test for DEV vs RTE in the web service? Does it even run as if it were in the DEV env? Is there a better was to detect this? thanks, -John

QUOTE (Mark Yedinak @ Mar 24 2009, 02:13 PM) Yes yes yes. That is very true. And that is exactly how I fixed it. My mistake was not realizing I was doing this in the first place. It wasn't untill I started using a large data set in the structure that the problem became more evident. But, after some work, liberal use of the inplace structure and addition of some shift registers, I was able to corden off the large data set and eliminate all reoccuring copies. The concept of a tree of variants stored in a single element queue as an efficient way of sharing data between parallel threads seemed like such a good idea. But, like every programming construct, it does have pitfalls. Maybe I should put together an NI Week session on the do's and don'ts of massive parallelism in LV programming. I think I have had to climb out of almost every pitfall there is over the last few years... QUOTE (MJE @ Mar 24 2009, 02:23 PM) I thought variants were really just handles, so a U32, or maybe U64 nowadays? So you're saying that running a variant down a wire from the queue copies the entire variant to the wire, all attributes and everything? The linked article below (very bottom) to me implies otherwise. I'd have expected LV to be smart enough NOT to make a copy of the actual variant unless you modify the data or attributes. -m That may be true, but if you preview the queue, you make a copy. I suppose if you dequeue it, the element you get is just a pointer to the same block of memory that the queue was holding on to. But even that may not be true. After all, if you dequeue all elements in a queue, the queue does not free the memory it used to store those elements. A queue hangs on to all the memory it has ever allocated. So, if each element takes up 1k and you had 100 elements in the queue at one time, then the queue is still consuming 100k, even if you flush it. Now, I do know that when I previewed the queue, even if I was just referencing an attribute of the variant that was a scalar, I did incur a memory copy of all the attributes of the variant. You can even see this if you turn on 'show buffer allocations'. Getting the large structure out of the variant tree and into it's own queue that I did not access often saved the day for my app.

No network drives. Local storage only. I am connected to version control (perforce). I do have a lot of .NET calls and I do use VISA in some places.

QUOTE (Neville D @ Mar 24 2009, 12:42 PM) Yes. The answer really is both. When you preview, it makes a copy. When you then get the attribute value, it makes another copy. And, I am pretty sure when you cast the variant value of the attribute to its LV datatype, it makes yet another copy. So, the worst case is when you try to access the large data structure in the queue element. But even if you are just looking as something small that is stored as part of the variant 'tree' you still incure one copy of everything.

QUOTE (Aristos Queue @ Mar 12 2009, 07:25 PM) In the end, the problem was not the clone setting but rather a very hard to find memory allocation issue. Quick tip: don't place a large data structure in an attribute of a variant that you store in a single element queue and access from several points in your app. If you do, then everytime you preview the queue element to read it, you will make a copy of the whole shabang, even if you are only interested in another attribute of the variant structure that is a simple scalar. This will eventually blow up on you. Took over a year to discover that one! So, now we are back to shared clones and all is well again... Oh, and the app runs 100x faster. Maybe I will have time to come to NI Week after all!

Am I the only one with this problem? Now I really feel alone...