LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 1/29/2007

Solved!
Go to solution
"The "08" flag is not required when opening a VI that is marked as "Entrant" ( is that the correct term for a VI where it is NOT re-entrant?). I seem to rember being able to use that switch to open re-entrant VI's as "Entrant" but I only have LV 7.1 and above on my laptop and can not test older versions."
 
Hey Ben,
 
I just got confused, as it seems like you've got the terminology reversed in what you typed into the forum on this thread.  "Get Occurence.vi" is in fact marked as "Reentrant", and the comment on the diagram of the dynamic caller also indicates this, but in your thread you refer to it as non-re-entrant.  That is unless I'm completely misunderstanding which VI you're talking about, but what you said makes perfect sense if you just replace "non-re-entrant" with "reentrant".
 
Regarding the comment above, you are correct, the 0x08 flag to Open VI Reference should not be used if the VI is not reentrant.  In fact, Open VI Reference returns an error if you use the 0x08 flag with a non-reentrant VI.  However that goes back to my previous comment.  I believe you are meaning to say that "Get Occurence.vi" is reentrant (not non-re-entrant).  If that is the case, then I think you should be using the 0x08 flag on Open VI Reference.
 
The reason I think it works without the 0x08 flag is that you are opening the VI strict type specifier. I believe when doing this, as required by the Call By Reference Node, Open VI Reference clones the reentrant VI even if the 0x08 flag is not set.  It took me a little bit to get this far, so I learned a little bit about the 0x08 Open VI Reference flag myself.  🙂
Message 21 of 66
(6,213 Views)

First of all, Congratulations Ben on this Nugget (or Boulder? 😉 )!  Very interesting subject indeed...

 


@drs Engineer wrote:
This gives me the idea that Occurences may be the way to syncronize one or more instances of a VI that controls, tracks, and/or simulates a thermal chamber while the UUT testing loop and UI update loops wait for and send occurrences to the chamber loop(s).  Hmmm...  I've been contemplating the best approach for creating an universal thermal chamber VI we could just drop in to any project that uses one.  Thermal chambers are so common that I would imagine someone has done this already.  Anyone willing to share how you did it and how well it works?
 
- Brad


Actually, I am headed there as well...  I have a number of vi's that will become universal as part of a "Universal" Test Interface.  There is usually a Thermal Chamber or Thermal Profiler attached to the test setup.  I do have to simulate it's behavior while developing code.  This Nugget showed up in time for consideration... 

RayR

Message 22 of 66
(6,215 Views)

Jeff,

All of your comments are correct! Thank you for "hearing what I meant and not what I said"!

Ray,

Thank you. When can we expect your Nugget?

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 23 of 66
(6,204 Views)
Hi Ben,


equested to close, the Occurnce should be marked as available to allow for the Occurences to be re-sued by another process.



Your suggestion was similar to what I was thinking of. I thought of using variants in shift register to create a two maps. Variant attributes act as binary tree map. The first variant would hold (occurrence, VI reference) pairs and the second variant (VI reference, number of occurrences referring to VI reference) pairs. The variant can then be used to look up the second value using the first value. In LV 8.0 and later this is quite fast. I tested such an implementation and it was 2 time as fast as notifiers in LV 8.20.

There is however one but. The action engine would still hold the VI references in a shift register unless explicitly forced to close. Even if the occurrences would not be reused, there would still be at least a few unused occurrences left out from the previous allocation and a VI reference related to these. So it would not be enough to request all occurrences to be closed but also request the action engine to close all unused occurrences and all the VI references related to them. So there would be a need for extra "Close Occurrence Engine" node. I don't like such nodes but I haven't figured out a way around. Of course one can rely on the fact that LV automatically disposes all the VI references of open VIs when the main VI stops running.

Tomi


--
Tomi Maila
Message 24 of 66
(6,160 Views)
Tomi wrote;
"
There is however one but. The action engine would still hold the VI references in a shift register unless explicitly forced to close. Even if the occurrences would not be reused, there would still be at least a few unused occurrences left out from the previous allocation and a VI reference related to these. So it would not be enough to request all occurrences to be closed but also request the action engine to close all unused occurrences and all the VI references related to them. So there would be a need for extra "Close Occurrence Engine" node. I don't like such nodes but I haven't figured out a way around. Of course one can rely on the fact that LV automatically disposes all the VI references of open VIs when the main VI stops running.
"
 
Good point. What if we changed the close the VI condition to be the 32 Occurnces are either marked for close OR Available?
 
I think you have got it!
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 25 of 66
(6,127 Views)
Message 26 of 66
(6,038 Views)
Greate job Jim! I'd still modify this so that I'd make Create function of subroutine priority and make the DLL call reentrant.

Tomi
--
Tomi Maila
Message 27 of 66
(5,952 Views)
Jim,

Have you tested if the LabVIEW call works properly when upgrading from older LabVIEW version to newer one? I mean if the DLL reference will automatically upgrade to the proper version of LabVIEW.exe or if it would link to the executable where it was created?.

EDIT: Jim, I took a liberty to modify your library. I made the following modifications:
  • I modified the VIs to run under LabVIEW 7.1
  • I made both functions of subroutine priority to speed things up, as a result call chain is not returned when error occures
  • I changed the library reference to be "LabVIEW.exe" from "/full/path/to/LabVIEW.exe" so that when opened in a newer version of LabVIEW, the proper executable is called.
  • I changed the library calls reentrant. However as the functions are not reentant, the is no risk of race conditions. I was not certain if functions provided by LabVIEW.exe are thread safe.

Tomi

Message Edited by Tomi M on 01-31-2007 11:59 AM

--
Tomi Maila
Message 28 of 66
(5,947 Views)

Nice post Jim!

Tomi has alredy asked the questions that I had except one.

How did you find this?

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 29 of 66
(5,928 Views)
Jim,

Can it be made platform independent? When I try to open it on my Mac it asks for LabVIEW.exe.

Lynn
0 Kudos
Message 30 of 66
(5,915 Views)