07-06-2010 05:03 PM
Hello,
I leave this idea due the reasons that you said.
I implemented my solution with Web Services instead of sockets. Web Services are supported in LabVIEW 2009, they work very good.
If you are interested read this topic please:
http://forums.ni.com/t5/LabVIEW/WebServices-labview-2009-gt-lt-Response-gt/m-p/1072024
Good luck!
07-12-2010 01:29 PM
I looked into Web services but ran into a major flaw in my opinion: Web Services run in a different application instance than the main LabVIEW instance. This means that you can't use the typical methods of communicating between VIs such as FGVs (LabVIEW 2 style global) or VI references. If you want to have the Web Service VI interact with an already running application, you must program a custom TCP/IP socket protocol server into your main application, or use built in network published shared variables. In the former case you have to program a TCP/IP socket server which in my mind obviates the need for Web Services, and in the latter case you can not pass Queues or User Events which makes them only good for simple data transfer.
I'll admint that the above is just what I've found through trial and error, it's quite possible I'm overlooking or missing a simple solution. However from the LAVA forum (http://lavag.org/topic/11192-interaction-between-web-service-and-main-instance-on-crio-target/) it seems like the two options I mentioned above are what we are left with. I'm assuming that if there were an easier method, those guys on LAVA would have found it.
How are you using web services and communicating with your main application instance?
~Mac
07-12-2010 02:46 PM
Hello Gaulinmp,
You doesn´t need to use sockets. I use shared variables fo this, it´s easy and simple.
You need create a LabVIEW project, inside you create VIs, shared variables, etc. It works perfectly.
Good luck.
07-12-2010 02:51 PM
Hi PedroTeixeira,
The problem with shared variables is you can't use them to pass the reference to a user generated event, or pass data through a queue to my main application. This means that all the shared variables are good for is passing simple data points or strings to and from the web service. I realize I could make a polling system that watches for changes in a string or integer, signaling that the web service VI has updated the shared variables, but this, in my mind, is not sufficient for a robust application. It really comes down to the fact that I can't program without events and queues, so shared variables don't suffice for me. Thus I'm using PHP and sockets to communicate with LabVIEW.
Thanks for the responses!
Mac
10-06-2010 11:41 AM
I am also trying to bridge the web server/services and main application instance gap. My current solution is to wrap calls from web service VI's to main app VI's inside of this structure:
Open App Reference (localhost) > Open VI Reference > Call by Reference > Close VI Ref > Close App Reference
(I started another thread showing this here)
I've got a few "global" resources that get called this way, and it seems to work well until it doesn't! And when it doesn't the entire LabVIEW dev environment drops from memory immediately. Sometimes I get a recovery dialog on restart, but most often not.
I'm still hunting for a more robust solution to this problem, or at least some company for my misery.
Thanks,
James