VST Driver

[JÞB]

---

@Hyrulian wrote:

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

---

Matt.

What I'm hearing from that is that I now have an instrument that does not behave like any other instrument.

NI DAQmx

NI-DMM

(or any other I/O resource type)

This saddens me.

[Hyrulian]

---

@JÞB wrote:

---

@Hyrulian wrote:

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

---

Matt.

What I'm hearing from that is that I now have an instrument that does not behave like any other instrument.

NI DAQmx

NI-DMM

(or any other I/O resource type)

This saddens me.

---

Jeff,

We came up with another solution that can be used through TestStand. There is a feature called Reserve Loaded VIs for Execution that preserves references that a VI creates during execution. It is located under the LabVIEW Adapter Configuration dialog box. Here is a link to the help document: Link

Sincerely,

Matt Graves

Software Engineer

National Instruments

[NJKirchner]

Jeff,

Your statement of 

"What I'm hearing from that is that I now have an instrument that does not behave like any other instrument"

Is not true for Modular Instrumentation, more specifically for all (that I interface with) MI drivers.

I primarily work with RFSA / RFSG along with a variety of other MI drivers. None of these drivers or the software sessions to them will stay active beyond the lifetime of the VI that initiates them.

I understand the desire to have your use case be valid, but as you currently have it coded, I would not expect any MI driver to behave properly like that.

In order to preserve the functionality that you're looking for, either NI behind the scenes would need to keep the drivers live for an indeterminate period potentially, or leave the power in yoru hands to declare that lifetime.

There are a variety of simple ways to enable your use case w/ out you requiring any kind of major re-write.

1. Make a simple VI that runs your INIT vi and stays running in the background
   This will prevent you editing your FGV but will easily allow you to run FGV in different modes to interactively test your commands/actions
2. Create a separate VI that gets launched when you run INIT on your FGV that init's the session, and hands back through some mechanism the referece to your FGV for usage in other places
   This will allow you to mess with your FGV as you wish but requires a little negotiation between launching a VI and passing a reference back
3. Make a stand alone VI that Runs the init, stays running, but puts the ref in a globally accessible data store (Q, Notifier, DVR, FGV, etc.) which gets checked at INIT
   This give you exactly what you want but you should check the ref out of the variable at init to make sure that it's valid.
4. Of course there is the idea of moving away from FGV, but if I get into that religious debate we'll totally hijack this thread

In a normal test program, you wouldn't be interactively running the FGV as you've noted you've been doing.

All VI would be loaded in memory, and stay run-time reserved for the lifetime of the calling program or even teststand sequence presuming that you didn't do a force unload all modules or dynamic calls to all VI

I understand what you'd like to have, because once upon a time, before I worked in the tower, I said the same statement to NI as a customer in your shoes.

The driver model for modular instruments is that in LV, the VI in which the reference was obtained needs to stay 'Not Idle' to preserve it's validity

I need to look into what happened w/ the DMM case tha tyou showed(would not have expected that), but even for your DAQmx example, it looks like that task was created elsewhere and you're not actually creating it, you're just accessing it by name which means that the task existed outside the scope of your VI.

I'm hooking up my PXI now to get some Screecasts and code running to post perhaps tomorrow.

Now for the matter of the VST where it's run by LV and not a traditional MI driver, we know exactly why this is the case.

No reference created in a VI has a lifetime beyond the lifetime of that VI. (With a minor exception of the Queue, where it has an obtain/release model when done by name and you obtain by name in multiple places)

That is the model of LabVIEW and personally speaking I'd rather have the auto cleanup model that LabVIEW provides than having to do 'malloc' calls to open memory references and close memory references all over the diagrams.

If you'd like a POC for any one of the specific options above I'll gladly toss it together for you.

Just let me know

Best regards,

Norman Kirchner

Sr. RF Systems Engineer

CLA, CTA, CPI, LabVIEW Champion Emeritus

~,~

[JÞB]

Thank you Norm,

I know your reputation. Still, an instrument that does not behave as an instrument, bothers me. I an shocked that YOU have not. Used similar structures.


integration really is that important too me.

[NJKirchner]

"Still, an instrument that does not behave as an instrument, bothers me"

Which aspect of 'an instrument' are you speaking of?

Is it just the idea that the instrument retains its state irrespecitve of the automation code that drives it?

If so, I agree that this is a difference between big box instrumentation and Modular Instruments.

More importantly so, w/ the VST being a software designed instrument, the role the calling software plays is even more important.

So for the moment, let's focus on what we need to do to fit your needs.

Will you be using the open Instrument Design Libraries to control the VST?

Previous posts made it unclear as to which software stack you'll be using, however it looks like in the most recent posts that the answer to that question would be yes.

From what I read, you said this runs successfully

It just happens to be that you want the use case of running the FGV independently (I presume for testing) to work as well.

Is this presumption correct?

Is there any other use case that you are trying to enable that is failing?

You said integration is really important to you, were you just refering to the usage of the FGV?

In this context what are you referring to for integration?

With regards to designing a system around FGV and me using that strucutre, I stopped using FGV over 7 years ago.

They have their purpose and make certain things easy, but so do Global Variables.

If you're interested in a very Scalable Modular Reusable Extensible and threadsafe alternative, the Extensible Session Framework (ESF) is what I use for this type of API

https://decibel.ni.com/content/docs/DOC-12813

From teststand, the above string of VI will work just fine being called from a sequence; as once the VI are called, they stay runtime reserved until Unload Modules is called (or if you choose a more agressive module unloading option(not default))

Best regards,

Norman Kirchner

Sr. RF Systems Engineer

CLA, CTA, CPI, LabVIEW Champion Emeritus

~,~

[JÞB]

It just happens to be that you want the use case of running the FGV independently (I presume for testing) to work as well.

Is this presumption correct?

Exactly:  As you may know I've specialized in design and integration of automated functional test systems.  These systems tend to get built with wires in the wrong locations and sometimes they actually do malfunction in the field.  The FGV approach gives me some tools for testing and debugging that I can explain to repair techs customers and co-workers.  My target audience is less skilled in LabVIEW than you would think so the approach has got to be easy for the novice LabVIEW user to comprehend.  "Resource Modules" fit that bill exactly!  Especially because all instruments I have used can maintain there IO session on a SR.  I can (and have) used workarounds to init and close with every use of the VST and, the SFPs do nicely for testing and maint.

Is there any other use case that you are trying to enable that is failing?

No, I am having good success so far though the first system is CW only I may run into some roadblocks when I get to the pi/4 DQPSK stuff

I did enjoy the ESF paper.  I like the Idea but then again you really do need to understand most of the Users and developers I have run across doing this type of work arn't really that savvy.  (I have one "developer" here who gets confused between auto indexing tunnels and Shift Registers But, he understands and can implement a "Resource Module")

Thanks again Norm.