LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DIO Read dominates cpu time...

When I do a DIO read with my 6533 device the read seems to dominate my cpu time. This is unaccepable since I have 3 DIO cards in my pxi chassis that I will need to use at the same time. It also interferes with data simulation since the cpu is dominated by this vi, it leaves no resources left for other vi's to use. I threw together a quick vi that simulates essentially what I am trying to do with this by editing one of the examples that comes with labview. Someone please tell me how I can make it so that the cpu is not dominated by this one function, or another way to do what I am trying to do. I essentially need to continuously acquire an unknown amount of asyncronous data from my dio card (of which I have 3) there is no hand
shaking, just a strobe signal which I have connected to req1 because the data is coming across port A. If there are any questions please let me know as I will answer them for you.

Thanks!
0 Kudos
Message 1 of 9
(3,519 Views)
Two quick thoughts. Make your main vi have a higher priority than the sub vi's. Make sure you are only initializing sub config type of vi's only once. Typically if you are in a loop wire the iteration counter to any sub vi's that require lower setup vi's to run only once. I haven't looked at your code as I do not have LV on this computer so if this answer is off base please forgive.
0 Kudos
Message 2 of 9
(3,519 Views)
Thanks for the answer but I don't really think this is the problem. If you (or someone else) could take a look at the code and let me know what's wrong I would greatly appreciate it.

Thanks again
0 Kudos
Message 3 of 9
(3,519 Views)
Hi Marshall,

Add another DIO read to the inside of you loop. Drop it front of the existing. Wire a read count of zero to it.

Take the baclog returned by this new VI and wire it into the "number of scans to read" input instead of your current constant.

Increase you wait time to 500 ms.

Now your VI will sleep for 1/2 second (freeing up CPU) and only read the data that is already sitting in a buffer.
Then it will go back to sleep.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 9
(3,519 Views)
Thanks, this was the perfect solution! I appreciate your time.
0 Kudos
Message 5 of 9
(3,519 Views)
I only have LV 6.0. Recompile the code in 6.0 format and I'll take a look at it.
0 Kudos
Message 6 of 9
(3,519 Views)
Oops,
Looks like Ben worked it out for you already. Thanks Ben. Disregard my last post.
0 Kudos
Message 7 of 9
(3,519 Views)
Oh well, there's another $500 consulting project down the drain (;^)).

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 9
(3,519 Views)
Lol, so there are a few lighthearted people on this forum. I was beginning to wonder..... 😉
0 Kudos
Message 9 of 9
(3,519 Views)