LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Matlab script reentrancy error

Hi all,

I'm encountering a bizarre error in Labview 6.1, and can't find any information about it in the product documentation or on the discussion boards.

I wrote a sub VI that calls a Matlab script, passing some inputs and retrieving some outputs.  I've been using this VI for some time without any problems.  A new system requirement has required that I make my sub VI reentrant so that different instances can keep their own individual state.  Oddly enough, my sub VI stops working when I make it reentrant.  The Matlab script returns error code 1048 (failed to get variable), and indeed it seems that none of my inputs/outputs are being passed to/from Matlab.

I realize that this error typically means that I have misnamed my inputs/outputs, but I stress that none of these has changed.  The only change is with regard to reentrancy.  It may also be worth noting that if I change the VI back to a non-reentrant state, the code returns to working order.

Has anyone ever encountered this problem?

Thanks!

cjb

0 Kudos
Message 1 of 8
(3,445 Views)
Hi cjb,

That observation sounds interesting. I looked for some documentation on this, but I also couldn't find any. Please let me know what version of MATLAB you are using and meanwhile I will try to reproduce the behavior here.

Thanks!
- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 2 of 8
(3,437 Views)
Hi Philip,

Thanks for your reply.

I'm running Matlab version 6.5.0.180913a Release 13.  It may also be worth noting that my VI structure is slightly more complicated than I described in the original post.  I'll describe it here:

My sub VI actually contains two more sub VIs.  Each of the three VIs holds some data in shift registers, and the bottom two VIs each use a (separate) Matlab script.  I have tried almost all combinations of reentrancy for the three VIs (ie I tried making just the top level sub VI reentrant, just the bottom two sub VIs reentrant, and finally all three sub VIs reentrant), but the problem appears in all cases.

I'll try to create a simple VI to demonstrate the problem, and I'll post it here later on Tuesday.

Thanks again,

cjb

0 Kudos
Message 3 of 8
(3,439 Views)
Hi Philip,

Ok, I believe I may have discovered the source of the problem...it's not Matlab after all.  There seems to be a problem when using property nodes in a reentrant VI.

Since my inputs are being referenced from several places in the code, I am using multiple property nodes to reduce the wiring complexity.  This worked fine in a non-reentrant VI.  In a reentrant VI, however, the property nodes seem to hold no value, and so null arguments were being passed to Matlab.

Are you aware of any issues regarding property nodes and reentrancy?

I've attached a simple example that illustrates the problem.  The input (1 or -1) specifies whether the output is incremented or decremented.  If the "Use Property Node" control is False, the output increments properly.  If it is True, the input never get to the Matlab code and so the output remains unchanged.

Thanks again,

cjb

0 Kudos
Message 4 of 8
(3,431 Views)

Hi cjb,

Ohhh yes, it is not recommended to use Property Nodes in reentrant VIs. This is because Property Nodes run in the user interface thread i.e. you read or write to the properties of the controls that are present on the front panel (user interface).

When you make a VI reentrant, you are creating a separate data space for each instance of that VI, but not a separate front panel for each instance. If you have a separate data space for each instance, then the front panel will not update the controls since at any point different instances of the VI can contain a different value for the controls on the front panel of the reentrant VI.  Since the front panel is not updated for reentrant VIs, and property nodes use the front panels to get the values, then for reentrant VIs, the property nodes will not reflect the changes.

R&D is aware of the limitations of reentrant VIs with regards to Property Nodes and they are looking into fixing this behavior for future releases of LabVIEW. For now, you should avoid using Property Nodes within reentrant VIs and as a replacement use Local Variables instead.

I'll make sure that this information gets documented in a KnowledgeBase too...

Have fun!

- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 5 of 8
(3,425 Views)
Thanks for the info Philip.
 
Just as a side note, I tried using a local variable in the sample VI I uploaded in an earlier post, and it performed as did the property node (ie it didn't work).
 
I've refactored my code to connect to inputs/outputs directly, and now everything works.
 
cjb
 
0 Kudos
Message 6 of 8
(3,421 Views)
Hi cjb,

That's weird - it SHOULD work with Local Variables. I have attached a small example that shows the difference between using Local Variables versus Property Nodes in a reentrant VI. Run the ReentrancyMain.vi multiple times and notice how changing the ReentrancySub.vi from non-reentrant to reentrant execution changes the result of the "Property" connection. Notice that the "Local" output is the same as the "Wired" output in any execution mode.



Have fun!

Message Edited by Philip C. on 08-11-2005 09:17 PM

- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
Download All
0 Kudos
Message 7 of 8
(3,417 Views)
Hi Philip,
 
It's quite possible that I did something wrong in using the local variable on my machine.  I am new to variables in Labview, as I have always used property nodes instead.
 
Thanks for all your help,
 
cjb
 
0 Kudos
Message 8 of 8
(3,409 Views)