LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reentrance in ansynchronously called Vis

Solved!
Go to solution

Never used a database with LabVIEW so take these suggestions with a grain of salt:

 

  1. You open a db Connection to each of subVIs. Is this necessary? Is the reference the same? Can you open the connection before you query and branch the reference? When you are done, you can close the reference at the end. I have no idea if a db reference is the same as other references. (usualyy opening a reference is a slow part)
  2. Parallel code requires everything to be reentrant, including subVIs.
  3. Your asynchronous calls don't seem to be of any advantage to a normal calling VI. The way it is set up everything happens in sequence. You could create your asynchronous VIs with "callbacks" that tell your program a result is ready. This way they would run concurrently.

mcduff

0 Kudos
Message 11 of 14
(312 Views)

That's part of the problem I'm having - I don't have a whole lot of experience with databases in general - and only intermediate LV skills.  This has been a learning experience to say the least, lol.

1) Whenever I open a single connection, an error is getting thrown.  Not really sure what is going on there, because that should work.  That's the next thing I think I'm going to try debugging.  My database team gave me an additional login to test, in the hopes the Oracle server was queuing the connections, but I was seeing the same lag with 2 unique logins as I was with a single sign on.  (I've been told by the database team, it is best practice to make a connection for each call to the database anyway.  Apparently the servers reserve connection information, so subsequent calls don't take as long.  Which is why I think I'm seeing at least 1s connection times on the first connection that is made and subsequent calls taking much less time (but all are coming in sequentially: 1st completes at 1s after the function is entered, 2nd at 1.15 after the first function is entered, 3rd at 1.3s after first function is entered, 4th at 1.45s after first function is entered - the sequencing is adding almost half a second).

2) If all of the sub .vis need to be reentrant, do I also need to create the asynchronous calls for them as well? or is making them reentrant enough?

3) Yeah, I didn't think I was doing the asynchronous calls right.  Not really sure how I need to do it in this setup. Or even if I need to?

0 Kudos
Message 12 of 14
(305 Views)
Solution
Accepted by topic author dbrown78

Bob Schor explained the difference between parallel and asynchronous calls earlier; I think you want to make sure your VIs are configured to run in parallel.

 

Right click the the VI icon and select VI properties, choose the Execution Category and check preallocated clone. Make sure all your VIs and the VIs contained within have this option if you want to do parallel execution.

Snap8.jpg

 

 

You open a database connection reference, for each query, not sure why you can't keep that reference and close it at the end. Anyway, I can see in your code where you close this reference. Not sure if that becomes a problem.

 

If you make your VIs reentrant than you should not need asynchronous calls, unless you want to run other things while these processes occur.

 

mcduff

 

EDIT: You open a database connection reference, for each query, not sure why you can't keep that reference and close it at the end. Anyway, I cannot see in your code where you close this reference. Not sure if that becomes a problem.

Message 13 of 14
(292 Views)

welp... i figured it out...

when I was initially reading into this, I found the link on asynchronous calls for parallel execution within the kb on reentrancy... and I guess I followed it down a rabbit hole.  All I really needed to do was make every subvi of the subvis reentrant and now I'm down to a total query execution of just over 1s.  which is within range of my target. 

Thanks for pointing me back in the right direction... doh!  

0 Kudos
Message 14 of 14
(282 Views)