Is there any of you ever be able to push more than 30 VI in the exported VI list of VI server?
I think I found a bug that is there since at least LabVIEW 2011.
WAIT... don't answer the easy one... "export all VI"... if you were about to answer that, that means you are not developing a safe application.
Thanks for any help.
I thought there was an easy, built in, VI server way of doing the following, but I haven't found one. Am I missing something trivial?
So I have one application instance, spawning clones of a certain VI. I would like to get an array of the VI refs of all of these clones. I thought I could via some property like Application:All VIs in memory, but I haven't found any suitable. All VIs in memory gets only the base VI names.
Missing that, I resort to register all my clones in a FGV as they startup, , and consult the FGV at will. Is there a more linear way?
I also note that I have to associate each VI ref with its clone name in the FGV, otherwise plain refs to different clones match as equal in lookups.
How do you decode, unpack a flattened string in python which was sent by a LabVIEW TCP server?
I want to exchange data via loopback. Therefore I take a sine wave and flatten it to string and sent over the network Simple TCP - ServerSINE.viSimple TCP - ServerSINE.vi. Then I have to decode the incoming data in a way that I have the correct numerical values like when I plot them in LabVIEW. I did this so far in python_client.py but the values are wrong.
Does anyone know how to work with the transferred Data in python?
By John Lokanis
I am running into an issue where my VI Server connection goes stale after a few hours. Looking for a fast way to detect this and recover.
Currently here is what I am doing:
On first call, open the application reference and then open the VI reference. Cache both of these. Use the VI reference to call the remote VI. On subsequent calls, test the cached references to verify they are still valid and then call the remote VI. What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails. Then I detect this and reopen the app and VI refs and can again call the remote VI.
The issues are:
The failing remote call takes a long time to timeout and I do not see how to control this timeout. The test of the refs does not actually test to see of the network connection is still good. The result is it takes a long time to recover and this is upsetting the user since it appears the system is locked up.
What I need is a way to control the timeout of the 'call by reference' node or a way to quickly test the references to verify the network connection is still good before I attempt the remote call.
By Gan Uesli Starling
Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail.
I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet.
My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being established, I may safely start the parent VI of which this VI is a sub.