Call to Reentrant VI trhough SUbVI

HI,
I have one doubt related to call to reentrant Vi's. My application(say APP) is calling a reentrant VI(say RA) has a nonrenentrant subVI(say NRB) which again has reentrant VI's(say RC) (hope not much confusing).
Purpose of VIs
Reentrant VI RA: As interface for udp read/write operation
NonReentrant VI NRB: Configures hardware through udp by opening udp port and does some IO operation
Reentrant VI RC: Does read/write operation through UDP read/write APIs'
Well my application APP runs perfectly on Windows environment but some of clones of RC remains on memory. On the other hand it does not work on RT target. Since I want to configure my hardware only once therefore NRB has been nonreentrant with function global variable to avoid reopening udp port.
I am struggling to identify my mistake if at all to have those code workable on RT target and should be flushed out from memory as well.
Please help if anyone has any clue on this.
Thanks in Advance
Vivek
Well my application APP successfully calls instances to RA and does the hardware configuration which is actually done by NRB through RC. The communication with hardware is through UDP and therefore

Hi
Could you please share your project with me so that I can look and try to figure out the problem?
Regards,
Ashutosh Singh

Similar Messages

Calling a reentrant sub-vi from a reentrant vi

I need to communicate with multiple identical instruments on different serial ports simultaneously. I have a set of vis that are the building blocks for communication, and they are all reentrant. I then have a top-level reentrant vi that is called multiple times with different VISA resources as inputs. That works fine, and I can see the multiple clones running, but the sub-vi calls from within that one are not being called in a reentrant manner, so each instance still has to wait for the others. I read that in older versions of LabVIEW you could not call a reentrant sub-vi from a reentrant vi. Is that still true in 8.6? If so, all my work to make these nice little building block sub-vis seems to be a waste. Do I have to use one reentrant vi that has all the sub-vi stuff unbundled and flatened out onto a large block diagram? If I replace sub-vi calls with reentrant calls by reference will that work? It is messier than a simple sub-vi call but not as bad as unbundling everything.

Mike,
Thanks for the update. Knowing that it is possible motivated me to dig deeper into why it wasn't working for me. It turns out that I neglected to mark one of my many sub-vis as reentrant and it was the bottleneck. Now that I have the whole heirarchy set to be reentrant everything seems to be working fine.

How can I Call the MainVI from its SubVI, and this happen recursively?

Hi All,
How can I Call the MainVI from its SubVI, and this happen recursively?
Actually, LAbView 7.1 doesn't support recurssion?
Plz help me out!

Dear GerdW,
Thanks a lot 2 all of u guys,for all the brilliant responses.
Actually, my basic aim is to call the Main VI, containing a SubVI.....
Now, I want to call my main VI from this SubVI...recursively!!!!!..but whenever I tried to put the MainVI in this SubVI..an error message pops out saying recursive calling is not possible.
I also tried using "Call by reference" but tht also didn't worked...an d error is somewat like...VI is invalid..or type matching..or state matching error.
Here, Im attaching the snapshot of the MainVI... Im calling the SUBvi from it... It is running GOOD n FINE...
But prob arrives when I call the Main from the SUBvi, which looks like same as MainVI(with little differences).
I hope, Im clear in my words n not being ambigous.
Plz, correct me where ever im wrong.
Thank You.
Mishra_RnD
Attachments:
ScrShot.JPG ‏272 KB

Resizeing an array of LStrHandles within Call Library Functio Node crashes SubVI.

Hello,
I try to resize an array of LStrHandles within a shared library. Here the C-code - attached a picture of the calling SubVI:
/* Call Library source file */
#include <stdio.h>
#include "extcode.h"
/* Typedefs */
typedef struct {
        long dimSize;
        LStrHandle elt[1];
        } TD1;
typedef TD1 **TD1Hdl;
long strArray(TD1Hdl arg1);
long strArray(TD1Hdl arg1)
        long err=0, count=2;
        err = DSSetHandleSize((UHandle)arg1, sizeof(long) + count*sizeof(LStrHandle));
        if(err) {
                printf("ERROR: 'DSSetHandleSize()': %ld\n", err);
                return err;
        (*arg1)->dimSize = (*arg1)->dimSize;
        return noErr;
I know there are a lot of threads, I read some and also tried the provided source code but somehow LabVIEW crashes. I don't know if it is valueable but when I change the following line it does not crash:
(*arg1)->dimSize = (*arg1)->dimSize;
Thanks for any help,
Johannes
OS: RedHat
LV: 8.2 Prof
Message Edited by [email protected] on 03-11-2009 12:26 PM
Solved!
Go to Solution.
Attachments:
subvi-resize-stringarray.jpg ‏7 KB

To be honest I'm not fully sure why that would crash but proper dealing is a lot more complicated than what you have done. The crash probably happens not in the C fucntion but on return of the function as LabVIEW tries to display the data. DSSetHandleSize() does not initialize the area it allocates additionally so there is likely garbage which LabVIEW then tries to interpret as string handles and consequently crashes.
You should also use NumericArrayResize() whenever possible as it takes care of various complications that can be hard to deal with on multi platform programs. NumericArrayResize() does use internally DSSetHSzClr() which initializes additional memory to 0. That would avoid the crash since LabVIEW does interpret NULL handles as the default for the according datatype, which would be here an empty string.
#include "extcode.h"
#if IsOpSystem64Bit
#define uPtr uQ
#else
#define uPtr uL
#endif
typedef struct {
    int32 dimSize;
LStrHandle elm[1];
} TDStrArr, **TDStrArrHdl;
MgErr MyArrayFunc(TDStrArrHdl arr)
int32 count = 4;
LStrHandle p;
    MgErr err = noErr;
/* The array could be non empty so dispose of any elements in it that are bigger than what we need */
for (i = (*arr)->dimSize - 1; i >= count; i--)
p = (*arr)->elm[i];
      if (p)
    DSDisposeHandle(p)
    (*arr)->dimSize = i + 1;
    /* resize the array handle to get enough space */
err = NumericArrayResize(uPtr, 1, (UHandle*)&arr, count);
    if (err)
return err;
    /* Fill in the data as desired */
    for (i = 0; !err && i < count; i++)
p = (*arr)->elm[i];
#if !complicated
      err = NumericArrayResize(uB, 1, (UHandle*)&p, 1);
#else
    if (p)
err = DSSetHSzClr(p, sizeof(int32));
      else
p = DSNewHClr(sizeof(int32));
        if (p)
(*arr)->elm[i] = p;
else
err = mFullErr;
#endif
    if (!err)
        err = LStrPrintf(p, "%ld", i);
    (*arr)->dimSize = i;
    return err;
Rolf Kalbermatter
Message Edited by rolfk on 03-11-2009 08:40 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How can i call a tree from a subvi?

I have a subvi which build a tree and give as an output a reference to it.
how can i display that tree on the front panel of a main vi. for instance press a button on the main front panel esecutes the subvi and display the tree on the main front panel.
thank you
diego

Hi
Put tree control on front pane of main.vil, create his (of control) reference and send it to your subVI
Eugene

How can I make a control inside a loop in a subVI change value when the calling VI's control changes?

Hi.
I think this is a pretty basic LV question, but I have not been able to find a good solution.
I am attaching VIs that show the problem I am having, but obviously, the real application is a lot complicated, which forces me to try to do it this way.
The issue is: I have a subVI with a Boolean control inside a loop. When the control is true I want some action to take place. When the subVI is run on its own, it works fine, acting properly when I set the boolean control to true via the LV FPGA interface from the host. However, when I use it as a subVI, in which the top-level VI calls several instances of the subVI, I have the Boolean controls in the top level VI. What is happening is that the false Boolean value with which the top-level VI starts is passed into the subVIs, and not updated, even though the control is inside the loop.
Can any one suggest a good solution?
Thanks,
AlejandroZ
Attachments:
CallingVI.vi ‏7 KB
subVI.vi ‏8 KB

Hi.
I know the example I posted might seem silly, but it was just to illustrate the problem I am having. In reality this is the application:
I have some LV FPGA code which uses a few FPGA IO to implement a serial link to communicate with a device. Most of the time we are getting data from the device, so the serial link is used to send a read command, read in the data and put it into a FIFO. However, I also wanted the VI to support sending data to the device, so I added an array control to put the data you want to send, and a boolean control to tell it you want to send it.
Since sending and receiving data are done using the same FPGA IO, they cannot be independent operations, because they would garble each other. Therefore, in the subVI I have a loop in which I first read data if there is any to read, then check the boolean write control to see if there is data to write.
As I mentioned, this works perfectly for talking to a single device. However, we run into the issue of this topic when trying to replicate this for several devices.
One easy solution is to not have the loop in the subVI, and have it in the calling VI (I am favoring this simple solution right now). The only reason why I have not done this yet, is that the subVI has more than one loop, so I am going to have to create several subVIs. I just posted to see if there was an even simpler solution...
There have been some other possibly good solutions proposed here, though I am not sure if they work in LV FPGA.
Thanks for all your responses.
AlejandroZ

Make a subVI do something on first call

Hello,
I have a SubVI I made and I want it to do one thing the first time it's called and then as long as the program is running it should do another thing. Right now I have a "First Call" function wired to it, and that passes it a tru the first time my SubVI is ecounterd and a flase every other time... this works... but I was wondering if there is a way to do this from within the subVI itself?
Thanks!
Solved!
Go to Solution.

Why don't you place the "first call?" primitive inside the subVI?
LabVIEW Champion . Do more with less code and in less time .

VI and SubVI reentrant

I developed some step types for TestStand in labview. Now I have an application where I need to use parallel process model. I guessed to set the step type as "reentrant". Here it is my issue. For setting a VI reentrant also its subvi have to be reentrant? This is a problem for me because the step type include a lot of VI.
Is there an alternative solution in TestStand or in Labview?
Thanks a lot.

If you want to have complete concurrency, you have to set ALL VIs in the hierarchy to be reentrant.
The default is non-reentrant because if you use shared resources (hardware interfaces, certain software interfaces/variables) setting the VIs to be reentrant, you will introduce race conditions.
Race conditions do act "sporadic" and therefore are hard to debug, annoying if occurring and can lead to severe issues with the whole system.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Reentrant Help!

Hi all! I hope everyone is well today,
Just to start off, I'm running Labview 8.2 on XP. Because of my company's concerns I have added images of a simplified
version of the vi that represents san example of what I'm trying to do.
That being said, here's my dilemma:
I am trying to call a subvi more than once simultaneously in my main vi. The only variable that will be shared is a single array, and it will only be read from, not written to, so there shouldn't be any data handling errors. The subvi that is to be called is set up as a reentrant, and the help file indicates that this is the proper method of handling this kind of repeated calling and simultaneous usage of a subvi. However, when I try to call the subvi a second time before the first call has finished executing, the second call will not execute until the first has finished. The help file indicated that this is what would happen if a subvi was called when it was NOT a reentrant. Can someone please help me trouble shoot this problem? I can't figure out if it is an incosistency in Labview or if I'm overlooking something! If this is not the proper method of calling a subvi more that once simultaneously, I'm more than willing to change my operations. Thanks,
Ryan
PS: To clarify, Reenrant.jpg is the "mainvi" here, and is the example of what I'm trying to do. Reentrant.jpg is the "subvi" that I'm trying to make simultaneous calls to.
Attachments:
Reentrant Execution.JPG ‏90 KB
Reentrant.JPG ‏29 KB

Valcon,
Even if you label a vi re-entrant it will still follow all the flow control rules of labview. So it will still wait for the error cluster, etc. to be passed out of the vi before moving on in the program. In the context of your program there it won't change anything to make it reentrant, since your while loop is going to wait for all of its contents to execute before moving on to the next iteration.
They way I like to handle this is instead of calling the reentrant vi in the normal way, call it by vi server. Instead of plopping your subvi on the diagram like normal, open a vi reference to the vi and choose the run vi method. Then instead of waiting for your vi to finish executing before moving on, it will launch the vi in a seperate thread and move on without waiting for it to finish executing.
-Devin
I got 99 problems but 8.6 ain't one.

Reentrance in ansynchronously called Vis

Hi all,
Recently I've developed an application that heavily utilizes a single GPIB communication SubVI, which writes a query and reads answers from a single device. In order to avoid collisions, I have deliberately set this VI as non-reentrant.
This SubVI is called by another VI, of course.
Now please consider this situation: what i run multiple instances of the caller asynchronously? Will the non-reentrance policy be respected?
I have hard times debugging the monstrosity I have created and I suspect I deal with collisions here.
Please share your thoughts. Thank you.
EDIT: I'd appreciate if anyone would also share a method of checking whether the GPIB instrument (namely Agilent ENA) is ready for query. I'd implement this mechanism just to be sure the non-reentrance is respected.
Solved!
Go to Solution.

Dear McTom,
Yes, when you call a non-reentrant VI anywhere in your code, even in asynchronous calls, only one copy will exist, so all other calls to that function will have to wait their turn until the current call finishes executing.
If you need a more sophisticated approach, allow me to suggest migrating your GPIB communication to another loop. You can create a queue to send requests to this loop, and pass the queue reference to all asynchronous calls. This way, you have the ability to closely monitor the loop status (number of elements in the queue, current element, status) as well as some advanced queue handling (priority messages, flush queue).
Kind regards:
Andrew Valko
National Instruments Hungary

Multiple instances of reentrant VI in a modular way

Is there a way to have a VI run multiple instances (in parallel) of the same reentrant subVI in a modular way, i.e. the VI needs to call n number of instances? Other than having n copies of the reentrant subVI hardwired in the calling VI (which is obviously not modular, or practical - imagine if I wanted to call 100 instances of the subVI), I am short of ideas.
All my attempts so far have failed, e.g. a single for loop (n iterations) containing the reentrant sub VI (with an indexed array passing information into the loop required for each instance of the sub-VI), however the loop will not move to the next iteration until the 1st instance of the sub-VI has completed execution (obviously, I suppose). Th
is is not the desired effect, as I want n instances of the sub-VI running in parallel. Other investigations into VI Servers have been unsuccessful as well.
Any help would be most appreciated.
Thanks, Paul

There was a discussion of this subject a few months back on info-labview. It involved the use of templates. If you do a search of the archives at http://infolv.brianrenken.com/ and specify .vit as the search parameter, you'll find a message from Kyle Gupton. See if his solution is what you are looking for. Good luck.

How do I change execution properties of a SubVi programatically

Hello,
I have a Vi that calls a SubVi from within several While loops. For that reason, the SubVi should be defined as Reentrant. The Re-entrant property works for the last version of the program but makes the debugging more difficult so, while I develop the program I don't set the Re-entrant property of the Vi.
Questions:
1) Is there a way to set the Re-entrant property programatically, in the initialization part of the program? That way I can use a Boolean variable called "Simulation" that is ON for debugging and OFF for using the program in the real world. That Boolean would be set at the beginning of the program, or maybe in the Registry, and would define, within a Case, the Re-entrant property of the SubVi. By the way, I'm already using the Simulation Boolean in two cases, 1) to set IP address of TCP/IP communication (real address for real application and 127.0.0.1 for simulation) and 2) to call a SubVi with calls to ImPort and OutPort in the real application and calls to a simulation SubVi when debugging.
2) In the same program, the main Vi calls a Re-entrant SubVi. The Re-entrant SubVi calls a set of other SubVis but only once in the SubVi. Shpuld the "second generation SubVis, sons of the Re-entrant, should also be Re-entrant? Several instances of those "second generation" SubVis may be running at the same time but each one called by a different process of the Re-entrant.
Thanks much,
Marce

Hi Marce,
You can change the execution properties of a subvi by using the Application Control tools. Open a reference to your VI. Use the application property node -> select class -> VI server -> VI and select 'Execution'.
Not sure on reentrant subvis but you can read this thread for some info.
http://forums.ni.com/ni/board/message?board.id=170&message.id=70767

Is there a way to store state of dynamically loaded vi without resorting to subvi tricks?

I have a VI for opening a UDP connection, retrieving data, and then closing the connection:
Setting state to 1 opens a UDP connection.
Setting state to 2 retrieves a UDP package. Most boxes above is for data manipulation.
Setting state to 3 closes the UDP connection.
Now, calling this vi as a subvi works just fine:
But, calling the vi dynamically doesn't:
The second call inside the while loop raises an error. Apparently, referenses are not valid from one call to the next when calling a dynamically loaded vi. What I need to know is, is there a convenient way around this?
Lars Melander
Uppsala Database Laboratory, Uppsala University
Solved!
Go to Solution.

Worked perfectly, thank you.
> Calling dynamically a VI inside a while loop may be pretty bad in terms of performance and I'm not sure that's a good idea.
Making the dynamic vi reentrant makes performance decent.
Lars Melander
Uppsala Database Laboratory, Uppsala University

Multitasking not working while calling DLL

This is my problem:
I have LV DLL based driver, every function in this driver is
reentrant, every DLL call is reentrant.
I want to communicate with number if instruments via this driver.
So I programatically clone the VI which communicates with instrument.
When I run all cloned VIs in parallel to communicate with all
instruments, the DLL calls are executed sequentialy.
Why there are not able to dynamically generate new threads ?

Greg McKaskle wrote in message news:<[email protected]>...
> > I have LV DLL based driver, every function in this driver is
> > reentrant, every DLL call is reentrant.
> > I want to communicate with number if instruments via this driver.
> > So I programatically clone the VI which communicates with instrument.
> >
> > When I run all cloned VIs in parallel to communicate with all
> > instruments, the DLL calls are executed sequentialy.
> >
> > Why there are not able to dynamically generate new threads ?
>
> It sounds like you have most of the correct settings, but let me review
> them anyway. First, make sure that threading is on in the
> Tools>>Options on the Execution page. It defaults to on, but sometimes
> gets turned off for compatibility with ActiveX or other nonthread
> friendly programs.
>
> Second, you say that your DLL calls are reentrant. If that means that
> the Call Library Function nodes have their checkbox set to show that the
> call can be made reentrantly, and making their color yellow instead of
> orange, then step two is taken care of. Otherwise make this change.
> You also mention that you cloned VIs. If you are using the same VI in
> more than one place on the diagram, they default to making a critical
> section -- allowing only one caller at a time. If you want to allow
> reentrant execution, this is set in VI Properties.
>
> Third, which I think is what is going wrong in your case, you need to
> have enough threads or execution systems to run your VI. You ask why LV
> doesn't generate dynamic threads. The answer is that LV preallocates
> threads that the VI needs to run and schedules nodes on those threads
> according to dataflow. Creating and destroying threads is actually
> quite expensive on most OSes, so that is not the mechanism LV uses.
>
> Here are several solutions for your system. Each VI and subVI can be
> set to run in a particular execution system and at a particular priority
> using the VI Properties>>Execution page. On a single processor computer
> each execution system priority cell defaults to having one thread. On a
> dual processor it defaults to having two, a quad defaults to four. In
> most cases this ends up being sufficient to keep the processors busy
> without causing excessive thread swaps.
>
> In the case where your threads are being consumed by a DLL call and
> therefore cannot multitask with the other dataflow nodes, you can either
> set your VIs to run in the different execution systems, or you can make
> the Standard execution system have more threads.
>
> To set the execution system of a VI, use the VI Properties. To change
> the threads per execution system, open the
> vi.lib/utilities/sysinfo.llb/threadcfg.vi or something very close to
> that name. This VI shows the threads allocated per cell, and hitting
> the config button at the bottom lets you change it. Note that as of LV6
> these numbers are the maximum limit allocated by LV and it doesn't
> allocate the threads in an execution cell until a VI is loaded that
> needs that system/priority.
>
> Now that I've told you how to do it, I'd recommend doing a very quick
> experiment with the execution system settings to see if there is any
> advantage to having multiple threads active. If the various threads are
> sleeping/waiting for hardware, this may indeed allow other threads to
> make progress, but if they are doing a spin-lock or heavy computation,
> there really isn't any benefit.
>
> Greg McKaskle
Dear Greg,
Thank you for your answer. I checked all the setting and I am sure
that I have these settings correct as you wrote. I tried the VI for
changing allocation of the threads, but the number of threads is too
small for me.
If I am right LV maximum thread number is number of preffered
execution system multiplied available priorities (App.Note 114), what
happened and how in threadconfig.vi is clear for you only (this vi is
locked, by the way number of locked vi's increases with LV version
number :-( - why this? )
I have from 50 to 200 points with same instrument on every point. So I
need up to 200 parallely running tasks for communicate with these
instruments via DLL based instrument driver, in every parallel task is
unique instrument session, but calling different functions from the
same DLL. Now I am not able to do it in LabView, only way is to use
LabVIEW native driver, but in this case I loose advantages of IVI
driver. Do you have any idea how to use IVI driver in 200 parallel
tasks?
Best regards
Jiri

Reading main VI front panel in SubVI

Hi,
I'm trying to create a subVI that writes a header text file containing info on essential parameters in my measurements. My mainVI front panel has a few dozen controls, some of them contained in a handful of clusters.
What I'd want is just to be able to access and read the values at the subVI to construct the string I want to write to the file.
I wouldn't like to proceed the dumb way, i.e., building an array of clusters or individual controls or references to them and passing that to my subVI (and, obviously not passing each individual control/cluster as a subVI input).
I figured I'd like to have some kind of refnum of the mainVI frontpanel passed to my subVI and dig use a big pile of property nodes to dig out the info that i need, inside the SubVI. Is this a feasible solution and if so, what's the way to conduct it? If not, what would be a better way?
As before, I'm using LV7 so in case you answer with block diagram examples, I'd appreciate screenshots of them.
Thanks,
Lauri

Vostokki wrote:
I'm trying to create a subVI that writes a header text file containing info on essential parameters in my measurements. My mainVI front panel has a few dozen controls, some of them contained in a handful of clusters.
What I'd want is just to be able to access and read the values at the subVI to construct the string I want to write to the file.
I wouldn't like to proceed the dumb way, i.e., building an array of clusters or individual controls or references to them and passing that to my subVI (and, obviously not passing each individual control/cluster as a subVI input).
Lauri
Actually that is the preferred way to do. Why you may ask? It is because you decouple the functionality (creating your log file header) from your specific user interface. By doing so you can reuse this VI in other places or applications. By using the references directly this ties the subVI to the calling VI. Unless the subVI is specifically doing something to the UI itself a subVI should avoid accessing data it needs via direct references. It should require the data to be wired in with the appropriate clusters, arrays or whatever your data needs are.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Call to Reentrant VI trhough SUbVI

Similar Messages

Maybe you are looking for