LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reentrant VI dynamically called by a reentrant VI

Hello guys,
I'have the following:
VI_1 Reentrant VI
VI_2 Reentrant VI
All SubVIs in VI_1 and VI_2 are reentrant
 
1 question:
Is it correct that all SubVIs inside a reentrant VI must be reentrant as well? (I did so, but I'm not sure that it is correct)
 
2 question:
VI_1 is called inside a while loop of my application
VI_1 does the following:
Open reference to VI_2 (Option = 0x08)
Set ctrl value [Variant]
Run VI_2 (Wait until done = TRUE; Auto dispose ref = FALSE)
Get ctrl value [Variant]
Close reference open
VI_2 by using a wrapper SubVI calls by Call Library Node a Multithreading safe method of a dll (the Call Library Node is configured as Reentrant)
 
What I see is that memory is increasing up to LabView crash.
Why? I thougth that closing reference of VI_2 would force LV to release memory allocated for VI_2 execution.
If I set VI_2 not reentrant and if VI_1 opens a VI_2 reference with option 0x00 It works.
Please help me.
Thank you
Federico
0 Kudos
Message 1 of 10
(3,848 Views)


@02Fede69 wrote:
Hello guys,
I'have the following:
VI_1 Reentrant VI
VI_2 Reentrant VI
All SubVIs in VI_1 and VI_2 are reentrant
 
1 question:
Is it correct that all SubVIs inside a reentrant VI must be reentrant as well? (I did so, but I'm not sure that it is correct)
 
2 question:
VI_1 is called inside a while loop of my application
VI_1 does the following:
Open reference to VI_2 (Option = 0x08)
Set ctrl value [Variant]
Run VI_2 (Wait until done = TRUE; Auto dispose ref = FALSE)
Get ctrl value [Variant]
Close reference open
VI_2 by using a wrapper SubVI calls by Call Library Node a Multithreading safe method of a dll (the Call Library Node is configured as Reentrant)
 
What I see is that memory is increasing up to LabView crash.
Why? I thougth that closing reference of VI_2 would force LV to release memory allocated for VI_2 execution.
If I set VI_2 not reentrant and if VI_1 opens a VI_2 reference with option 0x00 It works.
Please help me.
Thank you
Federico


Q1: No, all subVIs on renentrant VI don't need to be reentrant. However if your subVI is part of the recursive call chain, then it needs to be reentrant.

Q2: Your process is not recursive and you don't have parallel calls to neither of the VIs so neither of your VIs need to be reentrant. You don't even need dynamic calling by reference but you should be able to simply place the VIs on block diagram as subVIs.

If you insist using dynamic calling, then I recommend doing in the right way. Open VI reference with static VI type specifier connected to the top of the Open VI Reference node. Create constant to the type specifier, right click the constant, select browse and browse to VI_2. Then use call by reference node to call your VI_2. Then after the call close the VI reference you opened.

If you have LV 8.0 or newer you can also set up dynamic subVI call by right clickin on a subVI and selecting call setup from the appearing context menu.
--
Tomi Maila
0 Kudos
Message 2 of 10
(3,840 Views)
Thank you for your advice, I'm trying.
I need dynamic call because VI_ 1 is a generic driver for my DUTs.
Tests see generic driver and by time to time I point to the correct driver after user DUT selection.
The same test for different DUTs without code modification.
Moreover I have parallel calls that why I need reentrant VIs.
Last: Why my dynamic call is not correct?
Thamk you again
Federico
0 Kudos
Message 3 of 10
(3,832 Views)
As it seems that you were only paritial information I suggest that you post your code here so that those who try to help you know excatly what's going on and don't have to guess based on what you tell.

Tomi
--
Tomi Maila
0 Kudos
Message 4 of 10
(3,823 Views)

Tomi You are helping me and I'm implementing what you told me.

I only explain to you why I have to you use reentrant VIs called dynamically.

What I do not understand is: Do you think that my dynamic call is not correct?

I already correct my SubVIs making them not reentrant but the problem persists.

Only if I set the VI_2 not reentrant it works

Thank you

Federico

0 Kudos
Message 5 of 10
(3,818 Views)
No there was not anything wrong with you calling method other than it's not elegant and it doesn't work for headless systems. You can try to request deallocation with a node found from Application Control Palette.

I still would like to see you code, if possible.

Tomi
--
Tomi Maila
0 Kudos
Message 6 of 10
(3,818 Views)

Tomi.... I used Call by ref as you told me and it seems to work!!!! ; - )

As attached you find my code but consider that now everything is not reentrant.

Normally I used my VIs as following:

At the begining of my application

1 - GenDUTdrv - Configure.vi

2 - GenDUTdrv - Initialize.vi

Then

Any action (see GenDUTdrv - Protective - Get alarm message.vi as example)

At the end of my application

1 - GenDUTdrv - Close.vi

2 - GenDUTdrv - Dispose.vi

Waiting your feedback...

Thank you a lot

Federico

0 Kudos
Message 7 of 10
(3,810 Views)

Tomi I 've just verify that if a SubVI of a reentrant VI is not reentrant

then I've a serial execution on SubVI not reentrant without advantage

Fede

0 Kudos
Message 8 of 10
(3,805 Views)
Sorry there was more code than I though would be. I don't have time to brose trough that. You are right reentrant subVIs will not run in parallel. Sometimes this is a wanted behaviour and sometimes not. It's a good thing for example when you want to use an action engine or a functional global or when you have a subVI that simply consumer large amounts of memory. On the other hand if you want to make your process as parallel as possible then certainly you want all your subVIs to be reentrant as well.

Tomi
--
Tomi Maila
0 Kudos
Message 9 of 10
(3,798 Views)

Hi Timi,

I'd like to thank you a lot for your help. Everything seems to work.

Ciao e buona foruna [By and good luck]

Federico

0 Kudos
Message 10 of 10
(3,772 Views)