Jump to content

Dynamically launch VI can't pass DVR to caller

Stobber

By Stobber,
in LabVIEW General

 Share Followers 2

Recommended Posts

Stobber

Stobber 38

Posted
Posted

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.

I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)

DVRtest.zip

Link to post
Share on other sites
drjdpowell

drjdpowell 472

Posted
Posted
26 minutes ago, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

References are “owned” by the "VI hierarchy" that created them, and are automatically destroyed if that hierarchy goes idle.  Asynchronously-called VIs run in their own independent hierarchy (even if you use the Run method instead of ACBR).  In your example, the DVR was destroyed when the launched VI finished.  

Link to post
Share on other sites
LogMAN

LogMAN 178

Posted
Posted
31 minutes ago, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

The DVR will remain valid for as long as your dynamically launched VI is running (or rather for as long as the VI which created the DVR stays in memory). Since you wait for it to finish execution LabVIEW recognizes the VI as being idle and therefore removes any remaining references automatically. Reading the indicator value as variant doesn't help either, as LabVIEW cannot recognize the value as reference type.

You can try an FGV to store the DVR in a buffer (the FGV must create the DVR though), but this will work for one instance only.

Another option is to create the DVR in the caller and pass it to the dynamically launched VI. That's assuming the caller knows the DVR type => maybe use a subVI to create the DVR in the caller and pass it to the dynamically launched VI.

Link to post
Share on other sites
  • 4 weeks later...
  • 1 month later...
endeavor

endeavor 0

Posted
Posted

Norm,

let's assume I have two VIs that are running in parallel and sharing an ESF based session. VI 1 started earlier so it created the session whereas VI 2 found the active reference. Excellent.

The question now is what should happen when I stop VI 1 and it closes the reference with 'force destroy' flag set to FALSE. Should my session reference in VI 2 still be valid? Since the 'owner' is not running anymore I guess it shouldn't and this is also what I'm experiencing. Can you confirm it? If yes, I would like to know more about the version of ESF you mentioned.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Followers 2
Go to topic listing

  • Similar Content

    • Jim Kring
      Coerce Cluster (with single variant element) to Variant Bug [974336]
      By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • Axelwlt
      TDMS Read to DVR - Memory Usage
      By Axelwlt
      Hi
      I am reading big TDMS files (~1GB) and I try to minimize memory usage.
      I read a signal once and I want to keep it for later usage, so I tried to write it to a DVR in the hope that I have only one instance of the data in memory.

      However the task manager tells me that uses 2 times more memory than it should.
      I think the problem is that the array is not deallocated although I don't need it after writing it to the DVR.
      Is there a solution to make sure I don't have copies of data?
    • Ram Prakash
      Need to know about DVR
      By Ram Prakash
      Can anyone please tell what a DVR [ Data value reference ] is ? I want to know at what situation it will be used and what are the advantages we get by using DVR. I am really confused in this topic . If someone has any code in which they have worked with DVRs. kindly share it to me.
       
      Thank you.
    • Zyl
      Public DVR on a private class : access problems
      By Zyl
      Hi everybody,
       
      I'm running into something I don't really understand. Maybe you can help me here !
      I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions.
      In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions.
      In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem.

      But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks !

      The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library.
      I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection...
      Am I missing something ?
      DVR Private POC.zip
    • IpsoFacto
      Weird cRIO Behaviour with DVRs
      By IpsoFacto
      I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client.
      To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues.
      Here's a few screenshots of the code;
      Count Class process (get the count, increment, write it back to the DVR) - Counter Class process
      You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue.
      Server Side call - Server Side calls
      All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string.
      I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected.
      Any thoughts here would be welcome, thanks.
      edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists?
      edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept