6361 DAC Finite State sending information in transmiter buffer 100K samples, the error: "An unhandled Win32 exaption occurred in MultVolt...c"

[Sea-vain]

Hi, Paul,

Thank you for your help. How is going your tests?

Best regards,

Ilia

[Paul-B]

Hello Sea-vain,

I looked through some of the project files and was wondering if you could clarify exactly what your application is suppose to do. Also is the USB-6361 the only hardware you are using?

When you are running in continuous mode, your loop may be running so fast that it is overflowing the buffer on the card. As a result you are not able to transmit a buffer of more that 1000.

Depending on how you have your finite mode configured you may be getting an error as well. Make sure you are not running your finite mode inside a continuous loop.

Paul

[Sea-vain]

We are interested to use your DAQ 6361 boards for the simulation of the communication link, where two boards will be used. At the transmitting side in the DAC mode, when the signals from the PC output enter the DAC input with the data-rate 1.25MS/sec. And at the receiving side the signals enter the ADC input  and  ADC works at the  sampling rate -1,25Ms/sec.

Dear Paul,

Here are the details of our application 

We need the work in two regimes:

1. The transmitting PC will transmit the files of the volume up to 1GB and the data flow must pass through the DAC and ADC to the receiving PC and store in its memory for the following processing.
2. Real-time regime, when the data-flow from the transmitting PC (for example from its TV camera after processing) will pass DAC, ADC and follow receiving PC memory for the next processing  without missing the samples.

In the later E-mails we have described the problems, that we have met during attempts to realize said regimes.

In the first regime the problem was that the transmitting DAC does not permit to send the files, which volume is more than 100KB, and the receiving ADC could not receive the files of the volume more than 160MB.

The second regime we did not manage to realize at all, and we do not know if it is possible.  

Please, review our the projects that we have attached before, taking into account this explanation.

Thank you,

Ilia

[Paul-B]

Hello Ilia,

Are you doing single channel or multichannel sampling, because the maximum multichannel sampling rate is 1 MS/s.

In regards to the PC to PC file transmission you are describing are you using two USB modules for data flow. Also is this done using a real time operating system?

How did you determine the limitation in file size volume that you are describing?

Paul

[Sea-vain]

Hi, Paul,

1. We work in single channel sampling.

2. PC to PC link contains one USB module, working in both ADC and DAC mode. What do you mean as "real time operating system"? - our PC works in real time,  transmitting sinusoidal function.

3. The limitations we determine, when receive an error announcements, as you can see in the attached projects in our last e-mail.

Thank you for your kind attention

Ilia 

[Sea-vain]

Dear Paul,

Here is the more precise definition of our yesturday reply.

-          To point 2.

There are two different regimes, that are not connected one another.

The first regime is the transmission of the data-array of the fixed size from one PC to another, using two USB 6361. Now we have only one 6361 board and therefore we use it as DAC and ADC successively (DAC is using in the transmitting mode of PC and ADC is using in the receiving mode of the same PC ). So, this regime is not a "real time" and our question is - what is the limitations  in the size of the data-file, that we could transmit in such regime and how to change it.

What about "real-time" – it is another regime. In this mode under the term "real-time" we mean that the transmitting PC works in accord with our communication software, permanently sending the data to the RAM buffer of this PC, from which these data with the sampling-rate 1.25 Ms/s is transmitting to the DAC.

On the side of the receiving PC the board 6361 works as receiver in the ADC mode with the sampling rate 1.25Ms/s and the data must simultaneously follow to the RAM buffer of the receiving PC , and then this data is processed in accord with our communication software . This buffer should not be overfilled.

How could we realize this "real-time" regime?  

-          To point 3.

About limitations of the size of arrays  all information is in the zip file (sended you before):

1.For receive:Directory NiAcqIntClkInt;Project  file VC_Acq_IntClk.dsw;code file NIAcq-IntClk.c, line 47;

2.For transmite:Directory NI Cont Gen Volt Wfm-IntClk;project file VC-Cont Gen-IntClk.dsw,code NI ConGen-IntClk.c,line 57.

I've used for prototype the projects from NI ANSI C examples.

[Esteban_B]

Hi Sea-vain,

Taking a look at the project that working in, what you need to do is to use a code that will perform a continuous generation of data and outputs this data in the card, we have an example code that performs this operation, called ContGen-IntClk.c (you can find this in the ANSI C examples from the DAQmx examples for text base programming).

You need to change this code to non regeneration mode, this won’t allow NI-DAQmx to to regenerate samples the device previously generated.

You can do this using the command

DAQmxSetWriteRegenMode( your task , DAQmx_Val_DoNotAllowRegen);

After that you need to have a while loop and continuously write to the buffer the new data.

[Sea-vain]

Thank you for your reply, we follow your recomendations.

But you did not answer on other questions, concerning the volume of the buffers. May be it is not clear, what is our application?

Thank you,

Ilia