I'm having some trouble with the GE 5565 PIORC reflective memory set of VIs for use with our reflective memory setup. I need to copy a pretty sizable chunk of memory out of reflective memory and into a DLL I've written, but the performance on the "GE 5565 PIORC:GE5565 Read (Cluster).vi" is not where I need it. I need to copy somewhere in the realm of 12k out of reflective memory at a high frequency, but the call to read those 12k takes longer than the period I need to gather the data at. I apologize in advance for the image-heavy post, but I think it's worth it to show what I've got.
Here's a picture of my setup to benchmark the Read call runtime:
Here's a graph of runtimes of that Read call, in microseconds:
I need it to run in way less than 16 ms, which doesn't seem unreasonable to me for only 12k. I did fool around with the DMA version of the Read (which I don't really understand, and the documentation is nonexistent as far as I can tell). Here's my test setup:
And here's a chart similar to the one above:
Way better, though I have no idea if it even does what I think it should So, I have a few questions. First, is there any way to get better performance out of that Read VI? Some other library I should be using, some setting I should be setting, some other way I should be benchmarking its performance, maybe even some way of doing this with another DLL? Second, if the Read can't achieve the performance I need, what's up with the DMA version, and how would I use it properly? Is the performance advantage that it appears to be giving real, or just an artifact of some mistaken way in which I'm using it? Thanks!
Windows is not a deterministic operating system so the loop cycle time that you are getting might be the best time that the windows system can achieve. In order to benchmark your code you can also use the input node and the output node of the timed loop. Check the following link.
But it will be nice to know if you are working on a real time operating system or windows? Because unfortunately the windows operating system is not a deterministic system so the time loop might not work as expected. Here are a couple of links with information about this.
Which driver are you using for the GE 5565 PIORC? Is it this one?
If it is, please notice that this driver is neither supported nor certified by National Instruments. This card is supported with NI VeriStand. Please check the information on the following links.
I hope that this information answer your questions.
One point that is not answered here is the question of 16ms read time.
If the loop can be controlled to 1K on a Windows machine, why does the read time take so long?
I have a similar situation but was hoping to at least have 1ms reads.
The 1kHz Clock, is just the clock source. Keep in mind that you also need to configure the period. Also the execution will depend of the code that is inside in that case the code might just take 16ms to execute.
Even if we use a faster clock if the execution takes longer than the period of the timed loop, the timed loop will finish late.
Configure Timed Loop Dialog Box
Configure Timed Loop Dialog Box
In any Windows based system, every task is given priorities. As it happens, the priorities given to LabVIEW by the operating system are at best about mid-level. This means that any task that Windows gives a higher priority, gets the resources; all other tasks are put on hold. We had to take many of our systems off network to avoid much of this conflict. You can view the event viewer afterwards to display many of the resource impacts. Try turning many of the normal background programs off prior to your testing.