10-08-2012 02:27 PM
I am loading a simple MainVi w/Timer SubVI in Call Setup, ”Reload for each Call.” The problem is that the MainVI compiles the SubVI into memory, when setup is set to ”Reload for each Call”-Loads the subVI when the caller VI makes the call to the subVI if the subVI is not already in memory. This option does not guarantee that the subVI stays in memory after the call.
When I do it by using “Open VI Reference”, “Call by Reference” and “Close Reference.” The VI works by loading and unloading the SubVI in memory, which ”Reload for each Call” is supposed to do…..?
Solved! Go to Solution.
10-09-2012 08:25 AM - edited 10-09-2012 08:26 AM
anyone notice this problem,is there a fix or should i report this, please look at the link above.....
10-09-2012 09:25 AM - edited 10-09-2012 09:26 AM
A strictly typed static VI reference also reserves any subVIs when a top-level VI is reserved, thus making it ineligible for the Run VI method. Refer to the Run VImethod for more information.
LabVIEW loads the referenced VI into memory when you load the top-level VI. When the Static VI Reference function outputs a strictly typed VI reference, LabVIEW reserves the referenced VI as long as the top-level VI is running. LabVIEW closes this reference when the top-level VI is no longer in memory.
So the call set-up options really should be greyed out with static vi referances since the static ref loads the vi with the caller and cannot change call setup. With this mod to your code the call set-up pop-up is properly disabled
Also- Watch out for that infinate loop in MAIN2.vi (You really should not use default if unwired and have some means to stop on the second call
10-09-2012 01:56 PM - edited 10-09-2012 01:57 PM
What is really interesting about this feature is how easy it is to write the code that does not do what you want.
And presto LabVIEW rewrites your code for you to disable the ability to do what you just asked it to do.
I Think I'll wait for NI to weigh in on this before declaring it a bug but maybe there is a lack of understanding on my part.
10-09-2012 02:24 PM - edited 10-09-2012 02:25 PM
OK further reading through the help file.
I am/was confussed. The ACBR or CBR created by the call setup method does perform the way I expect. (It reloads the vi on each call) The Caveat that Apok and I missed is that it only reloads the vi if it is not allready in memory and does not "Force" removal from memory.
SO Apoks code MAY work differently with timer in memory and out of memory when MAIN2.vi is run. The Mod I made placed a Strict Type Def CONSTANT on the block diagram and the constant forces timer to be in memory. which was properly reflected by gyeying out the call setup options .
Thanks for straightening me out Jeff!
10-09-2012 03:32 PM
with this block diagram, it does as it is prescribed...."loads and unloads" it from memory. i just dont understand the "reload for each call"?
thanks for the research Jeff
10-09-2012 04:13 PM
@apok wrote:
thanks for the research Jeff
No Problem- I learned something new. You are not guarenteed to unload with a Call set-up. Although, I would suspect a call to request memory de-alocation would improve the chance that the vi unloads. If you try it let me know