LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV and multi-core, acquire data with DAQmx on dual-core

Hi guys,
in my program I acquire continous data with PXI-4472 and DAQmx (fs:40960Hz, 4096 samples).
I run this on two PC, one dual-core, the other one-core.
Sometimes on the dual-core PC, the acquisition seems "paused" and it "restart" after 5sec but the buffer could go on overflow. In these 5 sec on the task manager I saw one of the two core works at the 100%.
On the other PC one-core the program always works fine.
(I've got this problem also on a notebook dual-core with a 4472 Simulated device)

Someone of you got also this problem ??? and better someone can help me ?

Thanks a lot !!!

Michele
0 Kudos
Message 1 of 19
(3,988 Views)
Hi Michele,
what's your driver's version?
What are you using for developing your application? What's the version of the sw?
 
Thanx
 
R. 
0 Kudos
Message 2 of 19
(3,968 Views)
Hi Raffaella, on the two pc I use:
Max 4.2.1.3001
DAQmx 8.5.0f5
I have developed my program with:
LabView 8.0.1

thanks a lot

Michele
0 Kudos
Message 3 of 19
(3,962 Views)
Greetings Michele,
 
Thanks for providing the software information. On your dual-core PCs, in the Windows Task Manager have you verified the processor affinity for LabVIEW to contain both CPUs? If only one CPU is checked, then this behavior might be expected.
 
I was also looking for more clarification on "Sometimes on the dual-core PC, the acquisition seems "paused" and it "restart" after 5sec but the buffer could go on overflow.". If you believe it is not happening everytime, are you able to reproduce it consistently? Also, you mentioned that it "restart". Does that mean the data is lost during the previous continuously acquired data and it then restarts?
 
Hope this helps and let me know if you have gotten any further.
 
Happy programming,
Jordan Randall
National Instruments Italy
0 Kudos
Message 4 of 19
(3,916 Views)

Michelle,

I am using the same software, but my hardware is three USB devices, 6210 and 2, 6501

I am seeing a similar problem, almost seems random, but mostly occurs after running my application for an hour or more.

One of the messages I get includes the phrase "closed by host"..   The effect is apparentl loss of communication with the devices.

It occurs the same on an hp dual core tower cpu and a Gateway dual core laptop.

Just thought I would let you know you have company with this problem. 🙂

Fred

0 Kudos
Message 5 of 19
(3,894 Views)

OOPs:

     I got the previous error message wrong. The message is "transfer aborted by client"...  And that is with one core only via Task Manager in XP.

Fred

0 Kudos
Message 6 of 19
(3,891 Views)
Hi all,
I've verified that the CPU affinity contain both CPU.
I couldn't reproduce the error...it occurr randomly.
When it occur I see that the load on one CPU is 100%, on the oter 0%;

In my case I acquire on two boards (buffer of data) with two loop:
- PXI-4472: (priority 100)
    40960 Hz
    4096 samples
- PXI-6221: (priority 99)
    10000 Hz
    100 samples

I've put some probe: the execution is blocked on the DAQmx Read Data (PXI-4472) but the "Available Samples" increase a lot so I think that the acquisition continue but the program doesn't read the data.
About you it could be a problem of management of the two loop?

Fred, where you get these messages? So I check if I get the same.

Thanx
0 Kudos
Message 7 of 19
(3,862 Views)

Hello Michele,

If the affinity is set properly, then it sounds like a software timing issue. Are you using a producer/consumer design pattern? If so, what is your communication method (queues, notifiers, shared variables, etc.)? It's also important to verify if your while loops are using appropriate timing delays. What happens if you run the attached VI? Do both CPUs increase in usage or just one?

Regards,

Jordan Randall
National Instruments Italy
0 Kudos
Message 8 of 19
(3,854 Views)

Michelle,

I have the simple error handler on DAQmx Read Data command set in the vi for each device , does not seem to matter whether it is the binary or analog device that is first in line for execution... Almost always stops on the first one. In my case, if I remove a hub  serving the two binary carrds, the problem occurs much less often...  several days, on my last test...    So seems tto be a timing problem with USB I/O..  50 msec delays in front of the read vis seems to help also. I am a novice programmer, so I am probably doing something wrong.Why dual core machines make it worse, I don't know. I suspect an occasional pause in their execution for some reason.

Fred

0 Kudos
Message 9 of 19
(3,810 Views)
On a side note, I have recently had big problems with >certain< USB hubs.

I work a bit with USB spectrometers, and I had noticed that setting the parameters of a particular model wasn't working.  I was getting a failure rate of up to 80% when setting.  Imemdiate workaround was looping the set function until it worked.  Hardly elegant.

Then I came accross the reason for my problems.  I had the spectrometer connected to the USB hub of a DELL monitor.  Connecting directly to the host computer, 0% failure.  Connecting to a different hub on the same port as the monitor, 0% failure.  Connecting back to the DELL hub, 80% failure.

Other spectrometer types (from the same manufacturer) worked fine.  I suspect a power problem, but am otherwise unsure as to the exact problem.

Maybe it's a hardware problem.  If you have noisy or drifting power supply from the hub, it might be part of the problem.

If this is true, than the dual-core thing might not have anything whatsoever to do with your failures.  It might be the USB controller of the PC.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 10 of 19
(3,805 Views)