AnalogReadCallback no longer called in c# voltage acquisition application with reference trigger

[mwi_ch]

Hello

I'm writting a c# application using the DAQmx driver to do battery voltage measurements under different loads and load timespans. For that purpose I use a NI USB-6501 to control a testboard with the batterys and loads and a NI USB-6215 to acquire the voltage values previously to the loading and during the loading.

The acquiring is triggered by a reference trigger on the rising edge of the load control signal and the amount of samples is set such to acquire some single samples in previously to the trigger and during the whole load timespan.

The acquisition is mostly implemented according to the given example "AcqVoltageSamples_IntClkDigRef" and "ContAcqVoltageSamples_IntClk" with an AnalogReadCallback.

For some cycles (load and recovery) this works fine. But when I repeat them in the dimension of thousands suddenly the Analog Callback function is no longer called.

Is there a possibility to check the state of the task e.g. if it has aborted or do you now other possible problems concerning the callback.

Thanks in advance and best regards

[yamadj]

Hello mwi_ch,

To answer your question on checking the state of the task I don't believe that there are any ways through the API to do so. The closest thing that I can think about is using the Task State model; I've linked some info on the idea below if you are not familiar with it. Upon further research it doesn't seem like you can query at what state the task is currently at. So in short the API doesn't have the functionality to check the state.

Task State Model - https://zone.ni.com/reference/en-XX/help/370466AD-01/mxcncpts/taskstatemodel/

How to query DAQmx task state in LabVIEW? - https://forums.ni.com/t5/Multifunction-DAQ/How-to-query-DAQmx-task-state-in-LabVIEW/td-p/1515460

What might help to figure out what is going on is to figure out if there is an error being thrown and what the description of the error is.

If you are using the AnalogReadCallback example there should be a catch expression that pops up a message box if an error is thrown. Knowing if anything is being thrown could help both the forum and you figure out if what could be happening.

My hunch is that it might be something dynamic, like a buffer overflow/underflow since calling it more times causes the runtime error.

Feel free to post back and hopefully some more users can chime in and help us out.

Best,

[mwi_ch]

Hi yamadj

Thanks for your answer. Concerning the task state model, I'm familiar with it.

The suspect behaviour is, that the AnalogReadCallback is no longer called. It doesn't throw an error. I implemented a test output on the console window which is printed every time when the method is called thus I could figure out that the method isn't called. So my first thougth was that there is a problem with the NI device but I can "simultaneously" write or read in a separate task an other port, so the device is functioning as supposed. The possibility of an buffer overflow I considered as well. So I progammatically reduced the size of the buffer to a definite too small size. Then, as supposed, an error is thrown.

Since the the AnalogReadCallback is called everytime when the correct amount of samples is ready I came up with the idea that the task is no longer in the running state and thus no samples could be ready.

Do you have other critical issues? Could the used reference trigger depict a problem?

[yamadj]

Hello mwi_ch,

Thanks for clarifying the understanding to the forum.

Could we try to see if there are any available samples for the channel we're trying to read from? I think the function below could help. This way we can see if our DAQ device is even acquiring samples. If it isn't then we know to isolate something odd happening with the reference trigger.

[mwi_ch]

Hello yamadj

I will try this function to see if samples are available.

For the moment I defined a minimum amount of samples to acquire per trigger signal and a minimum cycle duration. These are 300ms acquiring samples and repeat the trigger signal at the earliest after 600ms. With this configuration it works reliable even when I don't know why.

Best regards