02-19-2007 09:53 AM
02-19-2007 10:28 AM - edited 02-19-2007 10:28 AM
It sounds like you are taking about an operator interface (OI). Teststand ships with a few example operator interfaces for different programing languages. Check out the example source code in the teststand folder \TestStand 3.0\OperatorInterfaces. Also, I would read the teststand manual section that discusses creating custom OI.
You can also run these examples from the start menu in windows.
Message Edited by paulmw on 02-19-2007 10:30 AM
Message Edited by paulmw on 02-19-2007 10:31 AM
02-20-2007 06:31 AM
OK, I know about operator interfaces, how to create/modify them, ... but that is not what I want to do!
I'm already running via a operator interface. Now I'm talking about a seperate screen, launched from within my sequence and running besides/in front of my operator interface.
The first time my sequence is executing I need to launch the dialog based window which contains the analysis result. This window never goes away (unless the user chooses to close it) Inside this window the analysis results can be seen.
The next time my sequence executes it detects that the analysis dialog window is already running so it will not launch the window again. But I also need to send my latest analysis results to this window so that the history graph gets updated with the latest information.
The only function of this seperate window is to show the latest measurement results so that the operator can see if there is a trend happening.
I need to know if there is an example of a simple communication protocol between a running vi and the executing teststand environment.
02-21-2007 03:44 AM
Hi noxus,
The basic design you are looking for is a daemon, This is basically a VI that runs in the background (your dialog VI for example). This VI is launched dynamicly when needed. And there should be a way of detecting if the deamon is running.
You can use various ways of communicating between VI's. The two most use full I find either Queues or TCP. The added bonus for TCP is that it also works over the Network, but could also be slower and blocked by Firewalls. Queues only work within the LabVIEW Process running on the Local machine and provide a nice way of detecting if the daemon VI is running.
Attached a example that show how you can implement something like this. The 'sent new value.vi' obtains a queue reference, we check if it has created a new queue or if it returned an existing queue reference. If the obtain queue created a new queue this means the daemon is not running and we launch the deamon.vi.
The daemon also connects to the same queue and maintains the reference. If the deamon is closed the referenced is closed as well and the queue is destroyed.
You can run the example VI. (in LabVIEW 8.2).
Hope this helps.
Thanks
Karsten
02-22-2007 02:16 AM
Thanks Karsten! That's exactly what I was looking for.