Reentrant execution?

Hi All,
Here's my problem. I've built a photon timestamping system. I have a VI that takes a counter channel as input and uses it as a clock. The input to the counter channel is the 80MHz clock onboard the PCI 6602 card. That VI works great. Now I want to instantiate it multiple times, each instantiation will be watching a different input channel. Someone mentioned that I should setting the reentrant execution option for this time stamping subVI in order to have multiple copies running. So I've set that, but so far only my second (I only have two instantiations to start with) instantiation is collecting data. Did I misunderstand the advice I was given? Is reentrant execution for if you want to go into the SAME instantiation of a subVI multiple times? So in this case I shouldn't have reentrant execution selected? Or if I should be doing something totally different please let me know. I've included my code for you to take a look at, there's two photon simulator programs there to to use with the code. Basically what I want to do is use multiple instances of the timestamper I've built and have them all watching different counter channels.
Thanks to any help,
Chris
Attachments:
LabView App (June 28, 2005).zip ‏158 KB

Chris,
I don't have compatible DAQ hardware here to test it, but I think I've got it fixed. Basically, one of those many many tiny little wiring connections wasn't routed properly to the first instance of your 'Single TimeStamping' module. The value of '# to read' went into the 'buffer size' input, and all subsequent wires along the top were likewise shifted one position to the left.
This would have been hard to debug because the modules, being reentrant, wouldn't have shown the values passed in on the front panel.
Unsolicited advice: try *really* hard to avoid using those 28-connector panes! It's very difficult to wire them properly, and you can usually bundle several input values into a single cluster input to save on wire count. Personally, I stick with the 12-connector pane for general use and never use more than the 16-connector pane.
Attached is a (hopefully) fixed version of the top-level vi.
-Kevin P.
Attachments:
CompleteTimeStamping_v5.vi ‏121 KB

Similar Messages

Reentrant execution problem

When I select reentrant execution in a sub vi, it seems to want to be turned on manually. When I create an executable the reentrant vi doesen't seem to run. Any ideas?
Thanks,
Tom

Hi Bob,
Thanks for your response.
Let me start by stating my task:
I have a program that I communicate with over active x. My Labview VI quiries with strings - and acts upon the responses. Some of these tasks are time dependent. Therefore I wish to create sub vi's that will thread these tasks at the processor level.
In the example attached (since you do not have the program, there will be no response string) the active x sub vi is reentrant. The flash vi is just there to crreate a timming issue for the threading to overcome.
If I run the reentrant test vi as normal, the active x sub vi will update as I click its run arrow. If I first select continuous run on the active x vi and then run the reentrant test vi, the desired
effect is achieved: continual updates to the quiry string that are not affected by the timming issues of the flash vi.
Is this the least bit clear? I hope so!
Thanks for listening,
Tom
Attachments:
reentrant_test.vi ‏15 KB
active_x_vi.vi ‏11 KB
flash_vi.vi ‏19 KB

[W2k, LV7]: debugging reentrant executions

Hi there,
I've entered unexplored territory in LabVIEW7 (at least for me).
My project involves the start of some daemons watching USB comm lines.
Those daemons are reentrant vis started using VI server: 'Run VI'. So far so good.
There seems, however, to be a bug in my code that prevents the self-termination of those daemons under specified circumstances. So now I need some help
debugging reentrant executions. Maybe someone of you can give me some hints and answer my Qs:
1. Those reentrant daemons have a non-reentrant subvi as a LV2-style global (USR to store 'global' data). Will this LV2Global run just in one instance as expected, e.g. can I rely on it displaying the results of all daemons?
2. I've created a little too
l that shows all running processes and if those are reentrant or not. But i can not figure out how to get the number of instances running of a reentrant VI. Any ideas?
3. If, as in my case, a reentrant daemon does not stop as expected, is there a save way to shut it down? I had to shut down LV using W2ks task manager to kill that processes. Any better ideas?
TIA and
Greetings from Germany!
Uwe Frenz

Hi Uwe!
I am used to seeing you on info-LabVIEW becuase I kunk on that list.
Yes, Ed's #3 is invalid for the reason you cited.
I do not think you should rule the VIT approach so quickly.
I have used VIT's to do this type of thing on a number of occations. Let me share my approach.
I will use an action engine that I use as a messanger to communicate Start/Stop/Exit messages to the VI instanciated from VIT's. It is a simple VI that uses the VI name to post messages from the daemon to the VI(VIT) and report status back.
How this works;
1) After the VI is instanciated using the invoke node "run do not wait" I use the reference to get the name of the VI that was created. I then use this name when I call my "messenger" to tell the VI to start.
2) The VIT's will first find out what their name is and then check my "messenger" to determine if they should start/stop....
3) The VI that launches the VIT's will use the "messenger" to check if the VI started OK. If not, I can abort and start the shutdown procedure and log an error after a resonable timeout period.
4) If the VI(VIT) started OK, the code will then procede to launch the next instance of that VIT.
5) When it is time shutdown the instanciated VI's, the same "messenger" is used to pass the shutdown message.
6) VIT's are coded to post their state (stopped, running, exit) to the mesenger.
7) When shutting down I can monitor if any of the instanciated VI's fail to shutdown and then log errors to give a clue as to which one was getting stuck.
The cool part of this approach is that all of the instanciated VI's show in the "hiarchy screen" and I can simply double click on the icon and get the FP open for that instance. This lets way I can do execution hightlighting to see what is happening without getting in the way of teh others.
Re#3;
I seem to remeber Rolf Kalbermatter lsiting this as with re-entrant VI's that he did not like.
Trying to repay you for "Info-LabVIEW" contribution,
Ben
Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Reentrant Execution gets slower.... (DATABASE TOOLKIT)

Hi All
I am LabVIEW 2009. Application is typically running on Windows XP.
I have a sub VI which is inserting data in MS SQL server. This vi is using database toolkit for inserting data into database.
I made this VI reentrant, and my toplevel is dynamically calling its clone.
Now suppose if my top level vi opens 20 clones of sub vi, everything seems to be ok. As per logic all 20 clones are inserting data into database parallely/second. (20 records/second)
Now, if my top level vi opens 100 or 1000 clones of sub vi, sub vi's are not inserting 100 or 1000 records/second into database. It means their executions speed decreased. (approx. 35 records/second).
Are my database VI's are creating this overhead or jitter. My SUB vi is reentrant, but when I diagnosed database toolkit, I found that almost all VI's are not reentrant.
After that, I edited all DATABASE toolkits VI's, I made all VI's reentrant, but still problem is unsolved.

Matthew Williams wrote:
As I understand it, the DB Toolkit .vis work through ActiveX, which itself is not re-entrant and may be a bottleneck.
We are battling the same problem, haven't found a good solution. It looks like we will have to go with two queues, one high
priority, one lower that only accesses the DB on a best effort basis. Not ideal.
From conversations with NI, I believe the LV 2010 DSC add-on is multi-threaded regarding DB access. Don't know whether
the improvements are available through the DB Toolkit, though, and we are stuck on 8.5.1 for this particular project.
Matt
Mike Porter has figured out how to get at DB using ADO and aviods the toolkits completely. He is way beyond me in this area but maybe that is an avenue that could help you.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

LabVIEW Functions and reentrant execution

Are the LabVIEW functions reentrant? I am writing a threaded application where the same code is used for the multiple threads. I have made the top level and lower level VIs reentrant but am wondering if the LabVIEW functions (specifically TCP Read and TCP Write) have only one instance loaded into memory or one instance is loaded for each VI instance that is loaded at runtime?
Cheers,
Wayne

> Are the LabVIEW functions reentrant? I am writing a threaded
> application where the same code is used for the multiple threads. I
> have made the top level and lower level VIs reentrant but am wondering
> if the LabVIEW functions (specifically TCP Read and TCP Write) have
> only one instance loaded into memory or one instance is loaded for
> each VI instance that is loaded at runtime?
The built-in objects in LV do tend to be reentrant. They are always
threadsafe, even when the access must be serialized such as for UI
actions. When the API has a connection ID or other reference to work
off of, they connect directly to lower OS APIs and are as reentrant to
the extent the lower level APIs allow.
Greg McKaskle

Attempting to Launch Data Control windows using reentrant execution using LV7.1

Need to get several devices connected to one Data collection System. Each Window will poll its assigned device and get a data packet which needs to go into a histograph. All the devices then need to pass their data back into the main window to be calculate the overall state of the system.
Now I am trying to create a single VI that will be reentrant and can be repeatedly called, handed a device, and go on it's way. I can't seem to get this idea to work though. I have included my testbed VIs I am trying to just get the reentrant code to open several FPs but with no luck so far.
and clues what is wrong with it or is this not possible on 7.1?
Attachments:
main.vi ‏84 KB
Secondary.vi ‏46 KB

I just can not figure out how to make my template "run" when I open it. It just sits there and doesn't do anything.
Attachments:
main.vi ‏86 KB
Secondary.vit ‏53 KB
Globals.vi ‏6 KB

VI Properties, Execution, Reentrant execution Tutorial

Is there a tutorial, how-to guide, or documentation about how reentrant VIs work, their requirements, and/or gotchas (prior to 8.5 improvements)?

I used reentrant VIs in two of my Nuggets (Occurences and Save-Restore) and the side-bar discusions chased down most of the challenges of using them.
You can find them here and here.
The only other note I can offer is that if you single step into a reentrant call (in LV 8.2 or 8.5 ?) and stopped the VI, LV would crash. THe work-around was to back out of the sub-VI call and then stop.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

How do you create a reentrant subVI whose instance is accessible using a refnum?

I am trying to create a hash table similar to the one create on the thread http://forums.ni.com/ni/board/message?board.id=170&thread.id=136037&view=by_date_ascending&page=2. That hash table uses unintialized shift registers to store the hash table data. The implementation only works for one hash table because if the function was made reentrant, there would be no way to access a specific hash table instance to perform operations. I am trying to write a hash table that is renentrant but with instaces accessible via a refnum. Currently, I am using a different subVI for each operation in a hash table class and passing a hash table cluster among the subVIs, but the bundling and unbundling induces too much of a performance hit.

You can do this by opening a reference to the subVI and then running it using a call by reference node. You can see an example here. Just note that you have to set an option on the open primitive to prepare the VI for reentrant execution (I think it's 2 or 8, can't remember).
If you want to see a more complete implementation, you can try downloading the OpenGOOP framework from OpenG, which uses this mechanism for data storage. Alternatively, you can use a queue to pass the data. If you have a single element in the queue and always make sure to dequeue and then re-enqueue, you should get a single copy of the data in memory.
You can also use variant attributes to do the lookup table. You can see more here.
Try to take over the world!

Execution Time Issue

Help Please!!!
I've been searching for an execution time issue in our application for a while now. Here is some background on the application:
Collects analog data from a cDAQ chassis with a 9205 at 5kHz
Data is collected in 100ms chunks
Some of the data is saved directly to a TDMS file while the rest is averaged for a single data point. That single data point is saved to disk in a text file every 200ms.
Problem: During operation, the VI that writes the data to the text file will periodically take many hundreds of milliseconds to execute. Normal operation execution times are on the order of 1ms or less. This issue will happen randomly during operation. It's usually many seconds between times that this occurs and it doesn't seem to have any pattern to when the event happens.
Attached is a screenshot of the VI in question. The timing check labeled "A" is the one that will show the troubling execution time. All the other timing checks show 0ms every time this issue occurs. I simply can't see what else is holding this thing up. The only unchecked subVI is the "append error call chain" call. I've gone through the heirarchy of that VI and ensured that everything is set for reentrant execution. I will check that too soon, but I really don't expect to find anything.
Where else can I look for where the time went? It doesn't seem to make sense.
Thanks for reading!
Tim
Attachments:
Screen Shot 2013-09-06 at 9.32.46 AM.png ‏87 KB

You should probably increase how much data you write with a single Write to Text File. Move the Write to Text File out of the FOR loop. Just have the data to be written autoindex to create an array of strings. The Write to Text File will accept the array of strings directly, writing a single line for each element in the arry.
Another idea I am having is to use another loop (yes another queue as well) for the writing of the file. But you put the Dequeue Element inside of another WHILE loop. On the first iteration of this inside loop, set the timeout to something normal or -1 for wait forever. Any further iteration should have a timeout of 0. You do this with a shift register. Autoindex the read strings out of the loop. This array goes straight into the Write to Text File. This way you can quickly catch up when your file write takes a long time.
NOTE: This is just a very quick example I put together. It is far from a complete idea, but it shows the general idea I was having with reading the queue.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
Write all data on queue.png ‏16 KB

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.

Event Callback from a Reentrant VI Recursion Error

Greetings,
I am using Register Event Callback with an ActiveX object to respond to user mouse events. The problem is that when I run the VI (the main, calling vi) as reentrant, Labview gives an error that the "Callback.vi" is attempting to recursively call "Main.vi".
Is there a way around this problem? I intend to run two copies of "Main.vi", so reentrant execution seems necessary.
- Colin Holbrook

Hi Colin,
Are you placing the Register Event Callback inside of the Main VI and then wiring the same Main VI to the VI Reference terminal? If so, then that explains why you are getting an error. You cannot use the Register Event Callback to call a VI within itself. If this is not the case, then please post a simple VI that demonstrates the problem.

Execution highlighting not working

I have a sub-VI with the following properties set:
Allow debugging
Reentrant execution
Share clones between instances
When I run the main VI with execution highlighting turned on for both VIs, the sub-VI never shows any action. What is going on here?

When you have a VI configured to be reentranant you need to open the specific instance of the subVI to use execution highlighting. Turning it on in th ebase suBVI has no effect because it is not referring to the specific instance in your application. Before you run open the subVI from the application itself, not the project. You should see a number appended to its name. Once you have the specific instance you will be able to use execution highlighting. One way to ensure you get the rightinstance is to put a break point in the calling VI right before you would execute the subVI. Then simply step into the subVI and turn on execution highlighting.
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

Again closing references and reentrant vi-calls

Hello,
i create a static-vi-reference that is then opened in a loop for 10 times in parallel. At the end i wait for all are finished. Then i close the reference that was created from "Open Vi reference".
Question 1: Do i also have to close the reference that is coming from "Static vi reference"?
(This 10x opening happens each second).
Question 2:
Currently the vi that is used as static vi-reference is set in VI-Poperties + Execution to "Shared clone reentrant execution".
What about all the subvis that are called in there? Do i also have to set them to "Shared clone reentrant execution" or is this done automatically?
Question 3:
I have the effect that everything seems to run fine but the CPU and memory increases
After starting the program 50 MB RAM and CPU at 15%
Then i can be seen that there are cpu-peaks from time to time, Seems as this are the parallel-calls.
Then cpu goes higher and higher up to 72% and ram goes to 230MB (after 4 hours)
Is ther something that can be changed in this mimic? There is nothing else running that can eat my cpu und ram.
Thx

OnlyOne wrote:
Question 1: Do i also have to close the reference that is coming from "Static vi reference"?
(This 10x opening happens each second).
No
Question 2:
Currently the vi that is used as static vi-reference is set in VI-Poperties + Execution to "Shared clone reentrant execution".
What about all the subvis that are called in there? Do i also have to set them to "Shared clone reentrant execution" or is this done automatically?
They are not changed automatically. If you want everything inside of that VI to run COMPLETELY independent, then you need to set the reentrancy for all of those VIs. If you want them to share information, then non-reentrant VIs is a good way to do that. So it all depends on what you want the individual subVIs to do.
Question 3:
I have the effect that everything seems to run fine but the CPU and memory increases
After starting the program 50 MB RAM and CPU at 15%
Then i can be seen that there are cpu-peaks from time to time, Seems as this are the parallel-calls.
Then cpu goes higher and higher up to 72% and ram goes to 230MB (after 4 hours)
Is ther something that can be changed in this mimic? There is nothing else running that can eat my cpu und ram.
I'd have to see what else is happening inside of your code. This could be any number of things, usually having to do with building arrays.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Reentrant web method VIs

The only mention I've found anywhere about using multiple web method instances is in this post:
"If the web method VI is marked reentrant, than multiple requests can be
handled concurrently (and your application logic should account for that
fact). If the web method is not marked reentrant, than only one
request at a time can call the VI and subsequent request threads will
block waiting to be able to call your VI." darenw, talking about web services in 8.6.
This makes plenty of sense and is what I expect. However, I find this not to be the case [using 2010 SP1]. My example is very simple:
Make the web method VI consist only of a "Wait (ms)" function set to wait for 10000 ms [10 s]. Check the "reentrant execution" box in the VI Properties dialog. Add the web method VI to a RESTful Web Service build spec and build and deploy. Then type the URL for the web method into two browser windows and send both queries at close to the same time. The first window will take 10s waiting for a response before finishing, as expected. The second window will take 20s--apparently the second instance of the web method VI does not start running until the first instance is completed.
Not only does this conflict the the quote above, but it's a poor behavior for web services in general [and it's fatal to my application in particular]. [To be complete I should add that running the web method VI in multiple parallel instances in the same container VI results in a 10s run as expected].
Is this a bug or what?
[this is an appendage to this ongoing discussion but is distinct enough from the original topic that I decided it should get its own--I apologize for the clutter if that was the wrong decision]

Just some more clarification
I did a similar test to pltrogon using LabVIEW 2010 SP1 on Windows Server 2008 R2 with a VI which waits 10 seconds and then returns the current time (hour/minutes/seconds). This web service VI is set to be re-entrant with the 'preallocate clone for each instant' option. It turns out the browser you use makes the difference, as seen from the time stamps returned:
Internet Explorer 9 executes the requests in parallel so multiple instances run at the same time. Five concurrent requests cause no difficulties.
Firefox 5 executes the requests in series. That is, it sends the second request as soon as the response to the first one has arrived.
That's why getting the page on two different computers shows the expected re-entrant execution.
As a check, if I set the VI to be not re-entrant, only one instance of the VI runs at the time, as seen from the times returned in the browser window.
My conclusion:
LabVIEW (2010 SP 1) is doing what is expected, you just have to use a client which sends multiple requests to the same page at the same time, and doesn't let the second request wait until the first request is finished.

Increment PtbyPt Reentrant

Under Other functions PtbyPt, there are increment Ptby Pt and decrement PtbyPt. Under Execution in VI properties, reentrancy is set to Preallocated clone reentrant execution. Does that mean I can use that VI to count multiple things? If that VI can be use for multiple counters, how does LabVIEw keep track?
Kudos and Accepted as Solution are welcome!
Solved!
Go to Solution.

There will be an instance for each call to that VI. Each instance (called a clone) will keep its own counter. To LabVIEW, they each act like totally different subVIs.
The LabVIEW Field Journal had a good series on maintaining state. I recommend reading the 5 part blog series. Part 1 can be found here:http://labviewjournal.com/2012/02/maintaining-state-1/
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Reentrant execution?

Similar Messages

Maybe you are looking for