Debugging Shared Variables with Desktop PCs

[DuffmanSays]

Frank,

Shared variables should be able to communicate between executables. When using shared variables in executables, you always want to be sure that the shared variable library is deployed as this will not happen automatically. You can do this manually from the project before the executables run, or programmatically. Another consideration when using executables is that the error dialogs will not show up by default when there are errors. Are you explicitly handling the errors using an error handler VI that will show a dialog? I might also suggest creating a debuggable executable so that you can see exactly where the client "hangs" in its execution.

Are you using a shared variable example from the web, or did you create your own client and server VIs? I assume that the server is simply updating a shared variable and the client reads from this shared variable and displaying its value. Please correct me if you've got a different setup. Thanks!

Mike D.
National Instruments
Applications Engineer

[Engelenfve]

Hello Mike,

I  amtesting the downloaded zip example and added a few minor alterations to see what is happening.

I added a second loop to see if Labview is hanging or the shared variable. If there is an error I display it but after that I clear the error and attemp to continue.

Deployment must work by using the invoke node, as I understood.

The answer to the prompt for the SVE path is to the server shared sv_lib.lvlib (which runs in the VI version).

I tried other paths and libs just in case, but no success.

Maybe you can try the attached zip.

Frank.

[DuffmanSays]

Frank,

With a few modifications of the bindings and deployment IP address, this example worked for me even in executable form. I also hard coded the paths just to simplify the example. You said that your client hangs in your test and this is why you added the additional loop. When you run the code, does the second loop appear to hang? Also, have you made this a debuggable executable so that you can watch the execution as if it were just a running VI? I'd like to further characterize the behavior that you see in the client application to suggest what may be the cause of the problem.

Mike D.
National Instruments
Applications Engineer

[Engelenfve]

Hello Mike,

I enabled debug in the advanced settings of both client and server. Running and debugging on the server works but on the client debug is not possible. ( after connect, debug waits forever till I end the client.exe ,which is still hanging, then debug reports "Failed to connect to the remote application").

Looking at the Variable Manager, I can get variables in the watch list (by copy /past the lvlib),  which shows variables are active (see attachment), but I cannot get the processes in the Variable Manager Tree in the normal way , as I automatically would see in the VI version. Maybe this is a lead for you?

After searching for days, trying all sorts of ideas, I don't know where to look now. I hope you can help out.

Frank

[DuffmanSays]

Frank,

As I mentioned previously, I am able to run this application by simply modifying the code slightly to run on my system. When your application runs (even as an executable), you should see the process show up in the variable manager. I should mention that even after the executable begins running that you would want to refresh the variable manager window so that you are sure the list you are viewing is current. If you have done this and are still having trouble, then we want to attack the two main problems it sounds like you are having now. First of all, the deployment appears to be a problem from the executables of both server and client. Secondly, it still sounds as if your client hangs when it runs. This is how I would break down the problem into individual components to determine the cause of the problems:

1) If both server and client processes do not show up in the variable manager, then you are looking at a problem in the deployment of the libraries. Does this happen when you run the VIs in the development environment? If not, then can you create a simple executable that just deploys both libraries to verify that this will work correctly?

2) If you still cannot view the processes deployed from a simple executable correctly in the variable manager, then there is a fundamental problem with the operation of your Shared Variable Engine. I would want to be sure that this is not specific to the installation on your test machine (as I have been able to run this code successfully). Can you test this on another system that is not using the same image and produce the same behavior?

3) If you still have problems programmatically deploying, is it possible to deploy the libraries manually and remove this section of your executable to test the functionality of your client and server?

4) If you are able to resolve or circumvent the deployment issue, then you can begin to focus on the behavior of the client. I assume (as you have mentioned previously) that the VIs work correctly in the development environment. If this is the case, then you will want to test your client and server when both run on the same machine. Only when this works would you want to move the client to your deployment computer. Does the application behave correctly when run on the same machine?

5) You should always be able to log into a debuggable executable. If the client is truly hung, then this may be why the debugger cannot connect. Again, you want to be sure that this is on the same machine initially. You can then ask what is different about the build or this code from the other VI that builds and runs correctly. Can you create any other executable that simply reads a value from a deployed shared variable? Is this build problem specific to this machine? Namely, if you build the same code from another machine, does it still exhibit this behavior? I would definitely be interested to know how to create an executable that hangs in the way you have described.

I apologize for the many different questions that are interleaved throughout this post, but hopefully this should show the way that we can break down this problem a bit. I hope these steps are useful for you to determine where the problem lies in this application on your system. Please keep me posted with your results and if I can provide any additional assistance along the way. Thanks.

Mike D.
National Instruments
Applications Engineer

[Engelenfve]

Hello Mike,

Thanks for the suggestions. Unfortunately I still have the same problems+1 new discovered. 

Is there a fundamental problem with the Shared Variable Engine?....I guess not.

In sted of addressing the shared variable, I made an other client using DataSocket addressing, which also uses the SVE if I understand correctly. This works fine on my PC and also on an other remote PC, after running the installer for this application.

Is there a fundamental problem with programmatically deploying shared variables and building an executable?....I guess yes.

Sequential tryings using the example method, shared variable addressing:

1. remove the invoke nodes in both server and client, manual deploy all in project, run Variable Manager >all processes are seen in the Tree, run VI version, no problem.

2.Build executables, Variable Manager still active, deploy all again, run server.exe...>now the server also hangs just like the client!  Exit the Variable Manager, deploy all again, run server.exe...runs with no errors, now run Variable Manager,refresh...no process in Tree! Client still hangs. Placing the shared variables in a case statement makes the client run untill I activate the case statement, ...client hangs as before.

3.Running the client.exe on a remote PC with programmatically deploy (manualy is not possible), in spite of above problems, manual deploy all on my PC,on the remote PC browse to my PC, after entering my PC no path and items to choose. (maybe I am doing this wrong)

4.Just for "fun" changed the Shared Variable property to "target relative" comes with an other new problem; "unable to build due to "broken VI" ,although there is no broken VI seen.  Setting back to "absolute" makes build possible again. **strange thing is it not?**

I hope it is clear what I discribed above and hope you can help me.

Regards,

Frank

[DuffmanSays]

Frank,

First of all, the DataSocket protocol can be a client to the Shared Variable Engine, but it does not use the engine. It is actually an entirely different protocol (shared variables use a protocol called PSP). So the other client is not necessarily a good test of shared variables as a client.

At this point, I am mainly concerned by the problem in which your VIs hang when accessing the shared variable node on the block diagram. This is definitely unexpected behavior that I have not been able to reproduce. It would be a good test to install the LabVIEW development environment on another system to run the VIs and executables. If this is not possible for you, then I would suggest a reinstallation of the LabVIEW software. Another suggestion would be to see if the executables would hang when using front panel binding. To do this, you can remove the shared variable nodes from your block diagram and just drag the shared variables from your project onto the front panel. This will create a bound control or indicator for your shared variable. This implementation of shared variable binding would tell us whether there is a problem with the nodes on the block diagram or the PSP protocol itself.

The error you receive when you build the executable using a target-relative shared variable is actually a known issue in LabVIEW 8.5. This was reported to R&D (# 4EBG02DT) for further investigation. You would need to use absolute binding in an executable that uses shared variables. There is a discussion of the shared variable node and its connection to the variable engine in the LabVIEW help. An absolute Shared Variable node always connects to the shared variable on the target on which you created the shared variable. A target-relative Shared Variable node always connects to the shared variable on the target on which you run the VI that contains the Shared Variable node. I hope this is useful for you. Please let me know your results as I would very much like to see this application working successfully for you. Thanks.

Mike D.
National Instruments
Applications Engineer

[Engelenfve]

Hello Mike,

Things I tried;

1. Re-install Labview (without un-install) on my PC...no results

2. Un-install Norton Anti-virus.. no result, re-install Norton anti-virus...no result

3.Run client with frontpanel binding. Fails with Application error instruction 0x7784298a in mem loc 0x1000009c, written failed (Dr.Watson event ID 4097 in log file)

4.Installed Labview 8.5 from DVD on a Windows XP Laptop, copied the project, ...Build warning,..removed files, tried to build new application.exe but the only item which appears is"new resource distribution" , I cannot build an executable or installer etc. , so ApplicationBuilder is not included?   Before Labview 8.5 , I had Labview 8.20 Full Dev.System and Labview 8.20 Application Builder seperately. After automatically received Labview 8.5 ,I received the message that Application Builder is included (no seperate delevery) but reading in the help shows that only Labview Prof.Dev.System has Application Builder included, NOT Full Dev.Sys.(which shows in the start-up logo).  It seems to me that N.I. update procedure failed resulting in all these strange problems, if so, I hope N.I. will send me the complete version a.s.a.p.

Frank

[DuffmanSays]

Frank,

I apologize for all of the difficulty that you have had thus far. The fact that the front panel binding gives this error tells me that the problem may be related to the Shared Variable Engine. Unfortunately I cannot find any other instances of this kind of behavior from shared variables or front panel binding. While I think that an uninstallation and reinstallation would be more effective than simply a repair operation, I would be more interested to test the same code on another machine. Do you have access to another machine onto which you can install the software?

Also, as you have found, the application builder comes only with the LabVIEW Professional Development System. I would suggest that you call our customer service department (800-531-5066) with your serial number for the application builder so that we can get you the appropriate activation code. Once you active the application builder in the License Manager, you will immediately have the capability to build executables in LabVIEW 8.5. This would also be an excellent test to determine if this problem might be version specific. Please let me know the result. Thank you again for your patience.

Mike D.
National Instruments
Applications Engineer

[Engelenfve]

Hello Mike,

It took me a while but there is some progress. I did what you suggested and installed on an other WinXP Laptop and on an other Win2000Pro machine Labview 8.5+RT module.

Eventualy I got both machines working client and server on local machine. Communicating between the two PC's took me again some time. The Firewall is not cooperating with me so I made a share folder for the server and added full rights to it. On the WinXP machine added to the exceptionlist tagger.exe and lkads.exe. Check and set Dcomcnfg settings etc. Everything works fine.

For my own PC there is little progress. Running client and server on local machine still hangs the client. Running the server on my machine and the client on an other machine works fine! Vica versa also works fine! ???  I completly removed and re-installed Labview, run RegClean,RegScrub,switch off Symantec virus scanner and many other tryings. Maybe I forgot to set or unset a property somewhere? I am afraid that I have to re-install Windows and everything else, unless you have another brilliant idea?

regards,

Frank