NI Home > Community > NI Discussion Forums

LabVIEW

Reply
Active Participant
JeffB_in_LV
Posts: 451

Re: Community Nugget 1/29/2007

"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.  :smileyhappy:
Knight of NI
Ray.R
Posts: 10,450

Re: Community Nugget 1/29/2007

First of all, Congratulations Ben on this Nugget (or Boulder? :smileywink: )!  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

______________________________________________________________________
Kudos!!!! Gimme Kudos!!!! It's that little golden star on the left below my avatar... :smileyhappy:
Knight of NI
Knight of NI
Ben
Posts: 16,102
0 Kudos

Re: Community Nugget 1/29/2007

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

Ben Rayner
Who is NOT John Galt... yet... just building Rayner's Ridge

Active Participant
Tomi_Maila
Posts: 419

Re: Community Nugget 1/29/2007

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
Knight of NI
Knight of NI
Ben
Posts: 16,102
0 Kudos

Re: Community Nugget 1/29/2007

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
Ben Rayner
Who is NOT John Galt... yet... just building Rayner's Ridge

Active Participant
Jim_Kring
Posts: 1,742

Re: Community Nugget 1/29/2007

[ Edited ]
Here is a simpler solution that makes calls directly into LabVIEW: Create_Destroy_Occurrence.zip

 

Message Edited by Jim Kring on 01-30-2007 04:20 PM

Thinking in G
Active Participant
Tomi_Maila
Posts: 419

Re: Community Nugget 1/29/2007

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
Active Participant
Tomi_Maila
Posts: 419

Re: Community Nugget 1/29/2007

[ Edited ]
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
Knight of NI
Knight of NI
Ben
Posts: 16,102
0 Kudos

Re: Community Nugget 1/29/2007

Nice post Jim!

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

How did you find this?

Ben

Ben Rayner
Who is NOT John Galt... yet... just building Rayner's Ridge

Proven Zealot
johnsold
Posts: 9,266
0 Kudos

Re: Community Nugget 1/29/2007

Jim,

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

Lynn