Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Device memory overflow with external clock and start trigger

Hi all,

we use a cDAQ 9188 chassis (DAQmx 15.5) and a 9205 module to acquire data from 2 channels with an external clock and start trigger. The maximum expected sample rate is 68 kHz for each channel. Most of the time this acquisition works but sometimes we get this device memory overflow error and our customer in China is not amused about that.

I set up a testbed here and can reproduce this behaviour, also with a Task in Measurement Explorer.

A bit strange for me is that this happens only every x cycles. If I remove the start trigger everything works fine!

Could someone please explain this to me? Is there any workaround?

 

Thanks a lot, Regards

Holger

0 Kudos
Message 1 of 10
(3,718 Views)

Hello Holger,

 

can you attach a screenshot of the error you receive and may be some reduced code?

Did you try to run an example with starttrigger?

 

Regards

Robert H

NI Germany

0 Kudos
Message 2 of 10
(3,628 Views)

Hello Robert,

 

thanks for your reply!

I tried an example, same behaviour. I also can reproduce this with the NI MAX so I don`t think that`s a problem of our code.

Tested this on different machines and today with the newest DAQmx version (16.0), same behaviour.

 

Regards

Holger

0 Kudos
Message 3 of 10
(3,601 Views)

Hello Holger,

 

basically this error indicates, that the data could not be transferred fast enough from the device to the host computer. This may have different reasons.

  • The network is so busy that the data cannot be transferred for whatever reasons (though the data rate should not cause problems)
  • The external clock is different from the specified rate

Basically there is only one starttrigger and the acquisition runs continously afterwards, correct?

Did you check the external clock signal? Maybe it has noise added.

Did you try to use an internal clock and if so, does this show the same behavior?

 

Regards

Robert

0 Kudos
Message 4 of 10
(3,595 Views)

@RobertH wrote:

Hello Holger,

 

basically this error indicates, that the data could not be transferred fast enough from the device to the host computer. This may have different reasons.

  • The network is so busy that the data cannot be transferred for whatever reasons (though the data rate should not cause problems)

 

  • The external clock is different from the specified rate

- I tested different data rates and also changed the network settings accordingly this KB: http://digital.ni.com/public.nsf/allkb/7BF7DE5ECD4081C7862577A00075E048

 

Basically there is only one starttrigger and the acquisition runs continously afterwards, correct?

- Yes

 

Did you check the external clock signal? Maybe it has noise added.

- Yes, there`s no noise and I don`t think that this is the problem at all because we get this error on different machines using different "clock generators".

 

Did you try to use an internal clock and if so, does this show the same behavior?

- With an internal clock everything works fine, also when I use an external clock without the start trigger!

 

Regards

Robert

 

During testing I noticed something strange:

I start the measurement task in MAX and it waits for the start trigger...

If I set the start trigger very close after starting the measurement, the error occurs.

If there elapses more time between start of measurement and start trigger, everything works fine.

 

Regards

Holger

 


 

0 Kudos
Message 5 of 10
(3,578 Views)

Hello Holger,

for the clock rate: If you specify the clockrate, does this match the actual external rate?

Is it possible, that the external rate changes during the acquisition?

Can you post the complete configuration part?

Are the trigger signal and the clock signal somehow related?

Basically the starttrigger should not influence the acquisition itself, exept from wait to start the measurement until it occurs.

Is the cDAQ connected directly to the host or through a bigger network?

If it's a bigger network, can you test with a direct connection?

 

Kind regards

Robert

0 Kudos
Message 6 of 10
(3,543 Views)

@RobertH wrote:

Hello Holger,

for the clock rate: If you specify the clockrate, does this match the actual external rate?

Is it possible, that the external rate changes during the acquisition?

- It`s the maximum expected rate the external clock could reach. Yes, the external rate changes during acquisition.

  I`ve tested this several times in NI MAX with different clock rates. There`s no error if I change this rate during a running acquisition. The error only occurs at start of acquisition.

 

Can you post the complete configuration part?

- I´ve attached some screenshots of the MAX Task configuration.

 

Are the trigger signal and the clock signal somehow related?

- Both signals are generated by the same frequency generator.

 

Basically the starttrigger should not influence the acquisition itself, exept from wait to start the measurement until it occurs.

- I´m sorry, but that`s what I can see here. A "long" period between start of task and starttrigger signal ends in a running data acquisition. A faster starttrigger ends in a memory overflow error.

 

Is the cDAQ connected directly to the host or through a bigger network?

If it's a bigger network, can you test with a direct connection?

- The chassis is directly connected to a gigabit network card and no other hardware is connected to the machine.

 

Regards
Holger

 

Download All
0 Kudos
Message 7 of 10
(3,522 Views)

One more screenshot...

0 Kudos
Message 8 of 10
(3,521 Views)

Hello Holger,

 

in this case I think it might be useful, if you contact the support directly. This makes the debugging easier.

 

Thanks

Robert

0 Kudos
Message 9 of 10
(3,469 Views)

Hi Robert,

I contacted the support in parrallel to this postings.

Yesterday I get the response that a CAR with number 539710 is opened to solve this issue.

 

But thanks for your friendly responses here!

 

Regards

Holger

0 Kudos
Message 10 of 10
(3,467 Views)