VST Driver

[JÞB]

Reposted from elsewhere

I am having some issues with the VST Drivers that are nagging me greatly.

In a nutshell I am developing several TestStand client sequences to test a familly of RF Products.  Using the latest VST version "VST (2.6.0.d5)" and No, that version is not publically available. 

Number 1 and the most pressing

VST Warm-up verification.  There is an oven in that device I can query the temp at last cal through a cal session.  I can't get the current temp  Wouldn't that feature be exposed with a simple #Extern?

2

Cal sessions.  They don't close as expected.  In fact they don't close untill the caller goes idle.  Taking the attached project I wanted to check cal date when initializing the RF in and RF out resources.  This worked fine untill I ran an initiallize all VI.  since the Cal session did not really close when requested the second call to open cal session errors.  Not nice.

3

Now that you see my Resource Modules you get the feel for where I'm going next.  Go ahead and init one then try to configure its output.  Every other instrument I've ever used will work through this structure but the VST generates error 1556 because the "Session Data reference" within the acquisition and generation objects die.  This is rather unfortunate since I now have an instrument that isn't acting like an instrument and I must Init, Run, Close in the same caller.  This would really handicap me if I wrote me sequence with steps like "Init VST Out, Change RF Params, Loop,"  Thankfully I usually write my test steps to contain all actions. 

Thank you

[JÞB]

OOPS

[Elizabeth_K.]

Hi Jeff,

Thanks for posting your questions on the VST. Due to the VST being a software designed instrument, it behaves a little differently then some of our traditional Modular Instruments, and I apologize for the frustrations that may be causing you.

I believe that some of your issues stem from the way that you are initializing an external calibration after opening a session using the Acquisition Class Open Session.vi. Since the VST is a software designed instrument, that means that the user can download their own bitfile onto the FPGA of the device. This is what is happening during the Open Session VI. Then, when you initialize an external calibration, it tries to download another bitfile (a bitfile created to support external calibration) to the device. As you can know, what happens when you run this code (all code is included in a project attached):

Is that you receive this error: (The error reporting on the Cal API does not return the LabVIEW FPGA error, I'll look into why that is).

To monitor the current temperature of the VST, you will need to use the VST Instrument Design Libraries. There are actually three temperature monitors on the VST, one on each portion of the device (Baseband card, RF In card, and RF Out card). The following code will tell you what the temperatures of the cards are. I've also included where on the palette the VST Instrument Design Libraries are located.

To get external calibration information, you will also have to use the VST Instrument Design VIs. That would look something like this:

Alternatively, the calibration information is available in the Acquisition Class and the Generation Class, so you could create a VI that took in the class wire and output the external calibration information.

I am not sure that I completely understand your #3. I think the information about not opening an external calibration session may be able to help with that. If it does not, could you include an example with all the code necessary? Since your Acquisition and Generation classes are located in your instr.lib, I can not open up the code that you sent without a lot of errors.

Also, I want to point you to a whitepaper about the software architecture of the VST that you may find interesting - http://www.ni.com/white-paper/14184/en

- Elizabeth K.

Note: In order to get the code under 6 MB, I had to zip it up without the bitfile. If that gives you an issue, please let me know.

[JÞB]

I'll post a better example tomorrow. but the vis depend on the simple VST Sample proj vis


To get "Is warmed up?" as bool cannot require modifying the bitfile. That is just not acceptable. CAR please.

Yes, you got older untested code. The cal sessions still do not close with close. I'll repost with examples.

So the worst and hardest to fix issue remain why can't the USR Data remain valid? Like any other I/O resource to an instrument?

[Elizabeth_K.]

Hi Jeff,

To get "Is warmed up?" as bool cannot require modifying the bitfile. That is just not acceptable. CAR please.

I don't really understand this statement, there is no need to modify the bitfile to get information about the temperature of the device. The code that I posted was all host code using a Simple VSA\VSG sample project and can be run using the bitfile that comes with the sample project.

So the worst and hardest to fix issue remain why can't the USR Data remain valid? Like any other I/O resource to an instrument?

I do not completely understand what you mean here. One thing that does make Simple VSA\VSG VST sample project different from the references of our traditional instruments is that it uses LabVIEW classes to pass data between VIs. It does not pass information from VIs in the acquisition session by reference, instead it passes it by value. I believe that is the issue you are running into, but if I am incorrect please let me know. Passing the class wire with a shift register on the while loop should alleviate this issue.

The way that your project had it's dependencies, and the fact that you renamed the classes in the sample project, meant that I would have had to browse for hundreds of VIs in order to open the example you posted. If you could send over something similar to what I posted, that would help me a great deal.

Thanks,

Elizabeth K.

[JÞB]

Elisabeth.

Thank you for the assistance.  The most pressing concern (Getting to the oven temperatures) is off the list and resolved.  Thanks for the demo.

Issue two the Cal Session not closing until the calling vi goes idle isn't pressing since I'm actually attacking the issue with the System Hardware API anyhow.   Although, it would be nice if the external cal date was actually populated when shipped. (Double check that NIs callibration process writes the cal date will you?)  I'll get the on line certs and load them manually but..... well all twelve of my VSTs will need to be loaded with that info. 

 Attached is the created driver that goes underlies the Project Attached in my original post (I hadn't figured you would name your driver different D'OH)

For issue 3 you wrote

" Passing the class wire with a shift register on the while loop should alleviate this issue."

As you see, That is exactly what I am doing! but as soon as the VI goes Idle Session Data Reference goes invalid and causes subsequent calls to return error 1556. 

[Elizabeth_K.]

Hi Jeff,

Although, it would be nice if the external cal date was actually populated when shipped.

Could you clarify your statement? When I run Get External Cal Info.vi from the project I sent you, I get cal data:

Is that not what you get?

Error 1556

Can you confirm that the error is only present when calling the VI from Teststand? That is, if you do the following, you do not get an error?

I am going to look into how Teststand handles class information and explore the implications of calling the VI from that environment. As much information about what you are doing and what you want to do will help in the debugging effort.

[JÞB]

---

@Elizabeth_K. wrote:

Hi Jeff,

Although, it would be nice if the external cal date was actually populated when shipped.

 Could you clarify your statement? When I run Get External Cal Info.vi from the project I sent you, I get cal data:

 Is that not what you get?

Nope, I get Epoch on at least the first of 12 VSTs and at least the first of 14 PXI 6509's the DMM (PXI 4065) is OK though

 

Error 1556

Can you confirm that the error is only present when calling the VI from Teststand? That is, if you do the following, you do not get an error?

---

It is not just a TestStand issue.  The VI shown above does work

The Steps to reproduce the 1556 error are:

1. Open the Resource Module VST Out.vi
2.  Select "Init" Command
3. Run the vi
4. Change Command to "Close"
5. Run the vi

Error occurs.

This is a very common use case for integrating the system to exercize the resources.  No other Instrument behaves this way.

[JÞB]

Although, it would be nice if the external cal date was actually populated when shipped.

Could you clarify your statement? When I run Get External Cal Info.vi from the project I sent you, I get cal data:

Is that not what you get?

Nope, I get Epoch on at least the first of 12 VSTs and at least the first of 14 PXI 6509's the DMM (PXI 4065) is OK though

Ahh Those two devices don't have that property! D'oh  OK strike that one off the list

[Hyrulian]

Hi Jeff,

Any reference type will be invalidated when the top-level VI that opened it goes idle. Even if you store the reference value in a functional global, since the top-level VI went idle, the reference is no longer valid. This is fundamental LabVIEW behavior, it happens with all reference types. Our traditional instrument driver handles are defined differently. For example, IVI session handles, such as RFSA/G sessions, keep all device state in a software cache. If your top-level VI is going idle, you have two options to continue in the next run:

1. Re-open any references when the VI runs again.
2. Store the class data in a separate data structure and restore the data when your VI runs again (When you are about to go idle, convert all your stored classes into some other data structure, where each reference is converted to some sort of ID so you can reconstruct it on the next run).

Sincerely,
Matt Graves
Software Engineer
National Instruments