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.

Re: Community Nugget 1/29/2007

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...

Re: Community Nugget 1/29/2007

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.

Re: Community Nugget 1/29/2007

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?

Re: Community Nugget 1/29/2007

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.