I'm writing code to interface with a Rohde & Schwarz ZNB Network Analyzer. I'm using LabVIEW 8.2 and TestStand 3.5. For reference the ZNB driver is available here: R&S ZNB Driver. I'm using a slightly older version of the driver, from before they required LabVIEW 2009. I'm writing all the code on a development machine that has the full version of LabVIEW/TestStand and running it on another machine that only has the TestStand Deployment License.
This driver links dynamically to some things that it needs. I am able to get it working with simple LabVIEW EXEs but not in TestStand deployments. The following excerpt is from their documentation, explaining a bit about how the driver works and how to use it in LabVIEW EXEs.
3.4.2 How to Build Executables or Libraries in LabVIEW The driver core of the attribute-based instrument drivers is dynamically linked to any executed VI during runtime. This cannot be recognized by the LabVIEW application builder. The LabVIEW application builder follows all static dependencies and includes them in the distributed package when building an executable.
To create an executable in LabVIEW, please manually add all VIs in the <instr.lib>\PREFIX \_utility\callbacks folder to the LabVIEW project. In case of project based driver please add the Private folder to your project. With this manual reference, the driver core is included in the build and the driver core is accessible during runtime.
I can't seem to get this to work in TestStand deployments at all. I can't even connect to the device since the Init VI has these issues. I get the same error for all the various attempts I've made. It is the same error as when you don't manually add the VIs for the LabVIEW EXE.
Property Node in Rohde&Schwarz Vector Network Analyzer.lvlib:rsidr_core_session_fgv.vi->
Rohde&Schwarz Vector Network Analyzer.lvlib:rsidr_core_check_error.vi->
Rohde&Schwarz Vector Network Analyzer.lvlib:rsidr_core_attribute_write_int.vi->
Rohde&Schwarz Vector Network Analyzer.lvlib:rsidr_core_attribute.vi:3->
Rohde&Schwarz Vector Network Analyzer.lvlib:rsvna.vi:2->
Instance 1 24Default Instrument Setup .vi:1->
Rohde&Schwarz Vector Network Analyzer.lvlib:Default Instrument Setup.vi->
Rohde&Schwarz Vector Network Analyzer.lvlib:Reset.vi->
Rohde&Schwarz Vector Network Analyzer.lvlib:Initialize.vi->
ZNB Connection Testing.vi
VISA: (Hex 0xBFFF000E) The given session or object reference is invalid.
So far I've attempted the following solutions, all producing that same error. I've been fighting with this on and off for a while so maybe there are some other attempted solutions I'm forgetting.
1) It looked like many of the VIs from the Private folder were ending up in SupportVIs. I manually pasted the rest in there too.
2) I added all the driver folders to my workspace and included them in the folders with the rest of my deployed VIs.
3) I added all the driver folders to my workspace and told TestStand to deploy them to the original driver locations in Program Files.
Does anyone have any ideas? R&S didn't even know what TestStand was, so they couldn't help me.
Solved! Go to Solution.
Error -1073807346 indicates that the VISA session is invalid, and this does not necessarily mean that the support VIs are not being located. It may be that you are not providing the proper initialization parameters to the VI in order for it to open the session or that the VI is unable to communicate with the device. Basically the prorgam is trying to execute some VISA commands on an invalid session which does not have a connection established.
You mentioned building an EXE from your program. Are you building it into an EXE which is then called from Teststand or are you calling the VIs directly from Teststand? If it is being built into an EXE then you will need to make sure that all the dependencies are included manually when the EXE is built. If you are running the VI directly from Teststand, you will just need to have the driver VIs available on the system in the same directly as your program VIs.
You're probably deploying the code incorrectly in TestStand.
How are you deploying from the dev machine to the deployment machine? Are you calling this instrument driver directly from your TestStand sequence? Are you using absolute paths to the VIs or relative paths to the VIs?
I was building little test programs using standalone LabVIEW EXEs without TestStand. Those all work so now I'm trying to deploy the full TestStand system which calls the VIs directly and doesn't use any EXEs. In my TestStand Deployment, the driver VIs that are directly called are being included in SupportVIs.
It's not that I don't understand the basics of TestStand Deployment. I'm modifying an existing program to work with a new type of network analyzer and that program is working fine. Everything should be set to relative paths. Even if something was set to an absolute path, I copied the driver itself to the exact same location on the deployment PC as it is on my development one and it still was causing that error.
Here's how I'm deploying. I'm not using any installers since all the LabVIEW/TestStand/etc programs are previously installed on this PC. The deployment utility creates a folder with all the files that I copy over to the other PC. Like I said before, this has been working for another network analyzer type that's part of the same program.
I'm calling VIs that include calls to the driver VIs. In the simplest case that I'm using to debug this issue, I have a sequence file with a single step. That step calls one VI that includes only calls to the connect and disconnect driver VIs.
please contact me via firstname.lastname@example.org so we can find a solution for your issue. I strongly assume that only finding the dynamic callbacks (VIs) is the problematic situation.
I was finally able to solve this issue on my own the other day. I brought the network analyzer to my office and did a lot of testing that way. Eventually, I found out that I needed to include the Private folder of the driver in the deployment, which I was doing in some of the previous attempts. It turns out that you also need to maintain the original directory structure of that folder when including it, otherwise the dynamic calls are not looking in the right location. Once that worked on my PC, I took it to the test machine and it worked there as well.