LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffer delay problem??

Hello
I am acquiring many digital inputs in my application and i have to scan them all the time and then use their current status in my following code...but the problem is that scanning of those digital inputs is very slow and i am not able to get the current status of my digital inputs.....although if I use just 2-3 digital inputs then the status changes rapidly.
 
I am attaching the code could anybody please help...I am just a newbie.
 
Regards
0 Kudos
Message 1 of 6
(3,399 Views)
Hi,

A general recomendation is to keep the size of your panels and diagrams to one screen.

Another is to minimize the use of sequence structures and local variables.

If you read your digital inputs as entire ports and separate the individual lines later it might speed things up. Depending on your hardware you may be able to combine several ports into a single group and read them all at once.

Separating the DAQ reads from the User interface via independent loops is also useful. Then each part can run at different speeds as appropriate to the tasks. Look at examples of "producer/consumer" architecture.

Lynn
0 Kudos
Message 2 of 6
(3,389 Views)

Hi, Thanks Lyn for the reply.

I am using many local variables also but does that mean it will slow my program by 15-20 minutes?????and I am not able to find producer/consumer example.....I using LV 8

 

Regards

0 Kudos
Message 3 of 6
(3,369 Views)
15-20 minutes is very slow. Are there some delays or timeouts that get repeated many times? Some of your subVIs are missing from the program you posted and DAQmx is not supported on my platform, so I cannot see everything that is going on in your program.

In LV 8 the Producer/consumer can be found in the File menu: New..>>From Template>>Frameworks>>Design Pattern>>Producer/Consumer Design Pattern (Events).

I thought searching the Help files would find a pointer to it, but it does not.

Lynn
0 Kudos
Message 4 of 6
(3,359 Views)
I spent a little more time looking at your program. Several things could be changed to speed it up.

1. This is a big one: Move all the Create Channel and Start Task VIs outside the loop to the left. Move all the Clear Task and Error Handler VIs outside the loop to the right. It is not necessary to create and close the tasks on every iteration of the loop. It takes time and does not achieve anything useful.

2. The user login VI and subVI: Is it necessary to log in on each iteration of the main loop? Do these VIs have a timeout if the user does not respond? If not, this loop can wait forever to finish. It appears that the output from that loop is the same whether login was successful or not: so why login?

3. The loop with the SET button will also wait forever for the button to be pressed. Parallel loops without delays (Wait (ms) functions or equivalent) can hog CPU resources and do not act very "parallel."

4. The large nested case structures at the top:
A. The outer structure is selected by the state value =0. In the False case the next value is set to 1. The outer stucture could be removed and in case 0 of the inner structure the next value is set to 1. Be careful with the "Use default value if unwired" setting for output tunnels. If the default case does whatt you want this can be OK, but if you forget to wire a case it produces the default whether you want that or not. WIth as many cases as you have, I would feel safer with avoiding the "Use default value if unwired" setting because you get an error if any case is not wired.

B. In Cases 6, 10, 13, 13, 16, 21, and 24 the Create Channel .. Error functions should be moved outside the loop as in item 1 above.

C. How many times do the cases with delays execute? Four cases have .25 s delays, one has 0.5 s and one has 0.9 s. These are far shorter than your 20 minutes but if they execute often it could add up.

Hope these suggestions help.

Lynn
Message 5 of 6
(3,354 Views)

Thanks Lyn.

Yes your suggestions helped a lot....actually the while loop for the login and another loop were creating problems and were responsible for delays.

Regards

Alankar

0 Kudos
Message 6 of 6
(3,341 Views)