02-15-2017 07:47 AM
Hi all,
I have a very specific problem with the functionality of the NI ECU Measurement and Calibration Toolkit 2.3
I am communicating via XCP to an ECU device and reading some measurement values with a defined sampling rate. Everything is working fine so far.
I use the mcDAQInitialize() and then the mcDAQRead() in a loop to get continously some values from my ECU.
I can see that normally after using mcDAQRead() , the amount of "mcPropDAQ_SamplesPending" is -1, which means that all data read from ECU.
But suddenly the DAQ functionality runs crazy and reads a lot of non-existent pending messages, also the "mcPropDAQ_SamplesPending" property is over 1.000.000 pending samples.
My problem is that with another software all values can be read constantly over XCP, so the ECU and the XCP communication seems fine.
Has anybody an idea for a solution with the rise of samples or a similar problem with the NI ECU Measurement and Calibration Toolkit 2.3?
Thanks in advance!
Best regards,
Simon
Solved! Go to Solution.
02-16-2017 08:49 AM
Hi Simon,
if you use DAQmx Initialize and Read in a loop, you try to start an aquisition multiple times and read all the values in the onboard buffer of your device. So depending on the timing configuration you chose, the device is acquiring samples and read only reads the samples from the device.
What do you exactly need in the end? An acquisition that reads sampels with a specific rate or samples being acquired when something happens in your software?
02-17-2017 12:48 AM
Hello Melanie,
Thank you for your response.
Here is what I am basically doing:
1. mcDAQInitialize() with a sample rate of 100Hz and 2 XCP signals to handle
2. while-loop with mcDAQRead () inside, which is reading always one number of samples
3. mcGetProperty( DAQRefNum,"",mcPropDAQ_SamplesPending, sizeof(DAQ_SamplesPending),&DAQ_SamplesPending) --> checking the number of samples
This is working very good!
But it seems that there is some bug or problem, because when everything is working, DAQ_SamplesPending == -1 after mcRead()!
But sometimes and I really don't know why, the number of pending samples jumps directly to >1.000.000! Can you tell me why or when this could happening with the mcDAQ module? It is happening randomly every 5 or 10 min and I haven't figured out why there should be so many pending samples in the measurement task...
Thanks for your help!
Best regards,
Simon
03-01-2017 08:43 AM
The Problem seems to be solved with ECU Measurement and Calibration Toolkit 15.0
Haven't had any more of those Errors or Problems since I installed 15.0
Also the Performance especially in debug mode is much better with 15.0, a lot less "ECU: Overload" Errors in debug mode!