I have a fairly simple DAQmx VI (attached) which I want to run on an RT system.
When i run th code (RDD2SC2 - Acquire.vi) on a Windows 7 system it is perfectly happy just sitting there using about 8% of the CPU. When i deploy it down to a RT system it maxes out the CPU, and while this is happening the shared variable is not updating properly (presumably because the CPU doesn't have time to deal with the SV?).
Does anyone have any suggestions why this VI could be hammering my CPU?
I have found some info here:
By adding a Read All Available Samples property node and setting it to true in the setup read VI, then having a start, wait until done, read, then stop task in my read vi (see attached picture) I have managed to reduce the CPU load to about 85%, which is much better, but still seems fairly high to me?
How many cores do you have in your processor? If you have fewer cores in your processor, they are shared between the OS pool and the TS pool. This results in overheads due to inter processor communication. Please have a look at this article which throws more light on how threads are assigned to processor cores in a RT system:
Thanks and Regards,
Thank you very much for your response.
I have tried two controllers, one has 1 core, and the other has 2.
I have changed the 2D array shared variable to singles (instead of doubles), and the dual core PXI seems to cope with it now, but it made no difference to the single core PXI.
I am using the LabVIEW 2012 RT module.
When I was using doubles i did try reducing the size of the array by a factor of 10 (120*21 data points instead of 1200*21), and this made no difference. So how come using singles instead of doubles works? I assume this just reduces the size of the array by a factor of two?
I just wanted to chime in with a few things here - your timed loop has a lot of nasties in it that you may want to reconsider.
Don't worry, everyone runs into this at least once (or in some people's case - like me - much more than once) in their quest for RT programming perfection. 🙂
Many thanks for the suggestions, they were very useful!
Attached is my modified code based on your suggestions.
I think I tried adding the 20ms wait to the timed loop to see if that helped, it didn't, but I forgot to remove it again. I understand now that was a very bad idea!
I've tried enableing the RT FIFO on the shared variables before, and the 2D array doesn't seem to like it, I get no error, the variable looks good in the distributed system manager, but when i use the read/write variable VIs to read it from somewhere else i just get an empty array??
The attached code seems a bit better, but is still using 80-90% of the CPU, do you think i can make it any better, or is this as good as it will get?
Yeah, I have a couple suggestions:
Give that a try.
Oh, and about the RT FIFO on the Shared Variable - only flat data types are supported in the RT FIFO, because all of their memory has to be allocated beforehand. I don't think you need to have an RT FIFO enabled on your shared variables (because of your use-case), but in general you don't want to read/write shared variables within the timed loop (the RT FIFO is just in case you absolutely have to, which in your case you did not).
Thanks for your suggestions, I'm glad you brought up the DAQmx stuff as I was a bit unsure about that!
If you notice in my very first set of VIs I was just doing the DAQmx Read inside the loop. When I added the Read All Available Samples property node and set this to true I lost all the timing structure in my 2D array. I want my array fixed at 21 by 1200 (21 channels and 1200 samples in 12ms, triggered). The array size started varying, I assume because the read just reads whatever is there, regardless of whether the whole acquisition has finished? Adding in the Start, Wait and Stop fixed this. At the moment it is set to finite Samples, should this be changed to continuous?
I didn't add a stop button or any shutdowns because when this is built to an rtexe and deployed down onto the RT system it won't can't ever be stopped. It probably would have been useful for development, but I had assumed it wouldn't take long to develop and I could get away without it!
Thanks for your help!
I've tried using continuous samples and wiring 1200 to the number of samples per channel input to the DAQmx read. This has fixed my array size again. I've moved to a producer/comsumer pattern (see attached picture) to strip back the read loop and avoid the -200279 error. My trigger is 50Hz, so I set the timed loop period to 20ms, this gave the -200279 error pretty quickly, presumably because I'm not reading the data quick enough and am filling up the buffer? This gets better if I reduce the period to 10ms, but presumably this means the loop will sometimes have to wait at the DAQmx Read because there won't be any data to read yet? Will this upset the timed loop?