LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Performance Issue

Hi all.

I'm working on a VI right now that makes use of a few of SubVIs.

The main VI has 2 parallel processes (while loops).

One loop contains 3 SubVIs (1 of which has a SubVI nested inside it, so fundamentally 4)

The other loop contains numerous SubVIs and most of these then contain shared functional global SubVIs I have created and other SubVIs.

It's evident that the loop with the large number of SubVIs is lagging severely (it is necessary to have them all in one loop as there is a flow of data from one to another, start to finish - and this flow is continuous, so data passes across and new data keeps on being input until the system is halted.

I have tried adding differing delays on the two loops - the top loop with 3-4 SubVIs appears to be running pretty much as expected in the profiling tool, but the other loop shows a severe lag and low number of runs for each of its SubVIs and their SubVIs, which is in turn causing problems as the system is reacting to input from these SubVIs either too late or not at all due to them iterating about 1/4 as much as i'd expect.

Does anyone have any suggestions for speeding this up?

I can't really post my .llb at this stage as it's a university project, but I can't see a way round having so many SubVIs in the large loop.

I could possibly do a screenshot of the SubVIs hierarchy when I get home shortly?

Any help very much appreciated.

Michael
0 Kudos
Message 1 of 29
(2,915 Views)
Hi Michael,

in general things to look out for are data duplicates (Especially if you're moving around large data sets), setting indicator or control values via the "Value" setting of a property node, UI updates via reference in sub-VIS and and and......

You could have thread conflicts, data copies, bad programming (we all do it), or other things.

It would be very helpful if you could post a pic of your code (no BMP please :p) so that we can hazard a guess at what the problem really is.


IT's also likely that any instrument communication may be limiting the speed of one loop, don't forget to tell us WHAT the loops are doing


Shane.

Message Edited by shoneill on 03-21-2005 08:02 PM

Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 29
(2,902 Views)
Hi Shane.

Probably easiest if I just put the .llb up

The 'Run.vi' file is the main program - the top loop inputs and outputs from an interface card - the bottom loop reacts accord to the state of input - it's very hit and miss - when the VI was smaller, it ran smoothly and sweet - now I've added a bit to it, there's a 50/50 chance of the 'sort area' actually reacting in time, usually firing the solenoid too late. The 'inspection' and 'reject' areas I am yet to do - saved the hardest until last! I have just added some dummys in to get an idea of how the program would run with all SubVIs in place.

The bottom loop are the stages of the application - it sorts pegs from rings, firing a solenoid to seperate the rings, increments counters accordingly, then assembles them with a solenoid, then the next stage I am about to work on is inspection and reject - I'm just worried that if I add too much complexity to either of these two latter stages and any more file logging to the other stages that the application will ground to a halt in terms of reaction times.

Many thanks,

Michael

Message Edited by Michael Burgess on 03-21-2005 07:14 PM

0 Kudos
Message 3 of 29
(2,896 Views)
any ideas guys?

cheers
0 Kudos
Message 4 of 29
(2,871 Views)
Your problem may be in the Conveyor area vi, where you have a one second wait...

CC

Message Edited by chilly charly on 03-22-2005 05:05 AM

Chilly Charly    (aka CC)

         E-List Master - Kudos glutton - Press the yellow button on the left...
        
0 Kudos
Message 5 of 29
(2,863 Views)
Michael,

It is difficult to give a definite answer without your hardware, but except for the DLLs which I cannot test, everything should run OK.

There are a couple of very odd programming choices. I don't understant your use of the notifier. Since you send and then immediately read the notification in the same loop it serves absolutely no function as far as I can see. I would completely eleminate the entire notifier track and place the input.vi inside the lower loop and wire its output to the green array there. No hidden indicator or local variable needed. (see image)

I would also call the portoutput in a loop for the two calls, there is no need to place it twice on the diagram. (see image)

Constant calculations belong outside the loop. (See image)



What are the loop rates that you are trying to achieve?

(edit: forgot to atttach image)

Message Edited by altenbach on 03-22-2005 12:01 AM

0 Kudos
Message 6 of 29
(2,862 Views)
Hi Altenbach.

Thanks for the reply.

Ah yeah - see your point on the notifier - that has been retained from an old method - going to remove it now and put the input in the lower loop.

I'm not sure how I could just use the port output once, as I am writing to a different port on the card with each call, namely Port A and Port C Upper. Using base address plus 4 and plus 6 respectively. But if there is a way of doing it then i'm all for it!

The upper loop seems ok on the profiler - the portoutput VI is executing a lot, as expected. It's the VIs in the lower loop that are probably only being run once a second or so, when I'd expect far more than that. I'm not needing anywhere near 20 times per second as i've tried to achieve with a 50ms delay - 200 or 250 would probably do the trick, but i've tried that and the same still happens 😞

Just wanting the VIs in the lower loop to execute a lot more 😄

Thanks for the help and thanks in advance for any more guys 🙂

Message Edited by Michael Burgess on 03-22-2005 07:57 AM

Message Edited by Michael Burgess on 03-22-2005 07:57 AM

0 Kudos
Message 7 of 29
(2,859 Views)
I'm thinking that this may be a problem definitely, I may have to put a shift register in the make sure that only happens once, as I only want that to wait the once, then stop - although I only added that last thing yesterday as a test to stop the bottom conveyor when there's nothing left in the system and restart when there's a peg and a ring present.

So, a subVI that contains a wait command - that wait will happen and it will effectively pause execution until that wait has been satisfied before carrying on with that subVI to completion, then starting the next? Hmmmmmmmmmmmmm

Thing is, I do need some wait commands in there, but want to stick with just these 2 parallel processes is possible to avoid having to pass data back and forth too much between loops.

Cheers
0 Kudos
Message 8 of 29
(2,853 Views)

@Michael Burgess wrote:
I'm not sure how I could just use the port output once, as I am writing to a different port on the card with each call, namely Port A and Port C Upper. Using base address plus 4 and plus 6 respectively. But if there is a way of doing it then i'm all for it!
See that image above, I originally forgot to attach it.
0 Kudos
Message 9 of 29
(2,849 Views)
Hey Altenbach,

what node is the one that is switching between 4 and 6 - can't seem to find it on the palette!

that looks like a very good way of doing it I must add! Thankyou!

I get the impression you've been working with Labview for a fair old while!
0 Kudos
Message 10 of 29
(2,848 Views)