03-21-2017 12:02 PM
Im am using v9.8.0 of NI-DAQmx, the NI hardware is a PCIe 6320 in a Siemens IPC running Windows 7 Enterprise. My software is writte in Delphi (and uses a Delphi adaptation of the C API).
We have been using this and similar setups very successfully for over a decade.
I am setting up an implicit buffered pulse measurement (for obtaining the high and low pulse lengths of a TTL encoder signal, counted in ticks) like this (only the parts that I think are relevant):
- I am calling DAQmxCreateCIPulseChanTicks with a minVal of 2 and a maxVal of 1000000.
- I am calling DAQmxCfgImplicitTiming, choosing continuous sampling
- After starting the task (which is done using an arm start trigger), I am calling DAQmxReadCtrTicks, where I choose to read whatever values are present (-1) with no timeout (0).
The error code returned by DAQmxReadCtrTicks is -224707 (which is undocumented), the error message reads "Internal Software Error occurred in C_API software. Please contact National Instruments Support. (-224707)".
(Note: I am also doing some other stuff in my setup, e.g. another one of the 6320's counters is used for a different counting task (quadrature encoder position). There is also other NI hardware present & used, like a PCI 6133 and a PCIe 6509. The error message happens only if I add the above to my otherwise happily working setup. So there is a possibility of "interference" with the stuff I do. Normally the NIDAQmx error messages are quite helpful in pinpointing the root cause. In this case, however, I triggered something bad ...)
Has anyone ever encountered this error message / code?
03-24-2017 08:45 AM
I am partially answering my own post here.
I have come to the conclusion that the combination of
does not work, the Read function fails on the very first attempt. A different error occurs if you change continuous sampling to finite sampling. (I tried both Delphi and C (Visual Studio 2015), the latter being a very reduced sample program derived from one of NI's examples. During my C experiments I encountered several BSODs when calling DAQmxRead... functions. I think that this is a sign of insufficient testing within NI.)
A very similar setup works, if you do everything using ...Time instead of ...Ticks (irrspective of continuous or finite sampling). So the ...PulseChanTicks feature seems broken (and untested by NI) to me.
03-24-2017 09:13 AM
I must make a further remark. The variant using the ...Time functions instead of the ...Ticks functions *only* works if I call the DAQmxReadCtrTime function with a positive number of samples to be read (and a nonzero timeout). If I (which I usually do) call it with -1 as the number of samples to be read (meaning "whatever samples you have right now") and zero timeout, a runtime error also occurs. Again a sign of incomplete testing.
There are no such limitations e.g. with all analog input tasks or quadrature (position) counter tasks I have used in recent years on a multitude of NI boards.
03-28-2017
08:37 AM
- last edited on
01-10-2025
05:35 PM
by
Content Cleaner
Hello,
first of all thank you for your question.
You wrote that you are using the DAQmx 9.8.0 version. Is there a special reason why you use such an old version?
I recommend to install the newest version 16.1, which can be found here:
https://www.ni.com/en/support/downloads/drivers/download.ni-daq-mx.html#288260
This version supports Win 7 and the NI 6320.
Can you please check if the error occurs after an update?
Best reards
03-28-2017 09:12 AM
Thank you for your answer and advice. Let me observe the following:
03-28-2017
09:15 AM
- last edited on
01-10-2025
05:35 PM
by
Content Cleaner
I actually found a useful link: http://www.ni.com/product-documentation/52784/en/
03-28-2017 09:26 AM
A quick read of the readme files since v9.8 of NI-DAQmx reveals no fix that sounds like it pertains to my problem. There is also a statement that says that more bugs are probably fixed than are shown in the readme file. So I am not sure how to proceed, especially since I found a working solution for my problem (i.e. using the ...Time functions).
03-29-2017 08:43 AM
Hi,
thank you for your answer.
Your worries about an update are vaild. It could be that changes has to be done at your system to fit to the new driver version. I also had a look at our internal database, but could not find an entry related to your problem.
After all it may be a good solution to stay at your current driver version and use the workaround.
If you decide to update the driver please let me know if it solves the problem.
Best regards