LabVIEW
Urgent Help Required
That looks like it should work. If you want to be totally sure, you could have created a constant from your Fetch's output. But looks good. Did this help with your problem?
What I meant was right-click on the output terminal of the USARP Fetch VI and select create->constant
Hi Attique!
If I understand correctly, the error only appears after a couple of seconds, which should mean that the VI works on the laptop and you gather some data, it just fails to be fast enough to process it all and eventually, the internal buffer of the task fills up. Could you run the task at a lower speed? That would make it certain whether it is caused by lack of system resources. The architecture you implemented looks good so far, I have some suggestions though:
-Try moving both data displays out of the producer loop, because updating them every iteration might take a bit of time. You can create a third loop for display like so:
the Preview Queue Element ensues that the queue is undisturbed and written to file without loss, and the Wait makes the display update at 50 Hz which is more than enough for fluid display yet still preserves resources.
- I would also move the control for Number of Samples out of the loop, to avoid front panel communication at every iteration.
- I suggest to set the Number of Samples to a multiple of 360, to ensure that all packets are of maximum size.
If all else fails, you can test your applications by ignoring overflow errors. To do this you must set Configuration>Advanced>Warning Policy to Return Success with a Property Node.
I hope this helps, please get back to me with the results.
Best Regards:
Andrew Valko
National Instruments
Dear Attique!
The Number of Samples for the acquisition useful to set because of the maximum packet size for the Ethernet communication protocol. You can improve throughput by ensuring that all Ethernet packets are full. For your device, I found that it is actually even higher than 360:
-16-bit sample width—multiples of 363
-8-bit sample width—multiples of 726
As for the setting, that is accessible via the niUSRP Property Node that you can find in the USRP libary (or just use a regular Property Node and then Select Class>IVI>niUSRP on the right-click menu).
I would advise to use it only for testing though, because what this does is it sets your Read to ignore overflow, underflow and timeout errors. To quote the help page:
Short Name: Warning Policy
Property of niUSRP
Specifies whether NI-USRP returns an error, returns a warning, or ignores overflow, underflow, or timeout conditions during data transfer.
Default Value: Return Errors
Supported Devices: NI USRP-2920/2921/2922
| Return Warnings (0) |
Returns a warning when an overflow, underflow, or timeout condition occurs during a data transfer. |
| Return Errors (1) |
Returns an error when an overflow, underflow, or timeout condition occurs during a data transfer. |
| Return Success (2) |
Ignores overflow, underflow, or timeout conditions during a data transfer. |
I'll be waiting for your results!
Best of luck:
Andrew Valko
