OnDemand after Source Clocked give "internal error status -88700"

[whemdan]

Hi,

I am using Analog Input and Counter Input simultaneously with a shared internal clock source on the NI PCIe-6363

I'm running on WinXP, with NIDAQmx Driver 9.1.1f0

I start off by doing some OnDemand acquisitions and it all works.

Then I configure the task for Sample Clocked acquisitions and everything works.

Then I try to configure the task back to OnDemand using DAQmxSetSampTimingType, but when I start the task I get "DAQmx Error: An internal error occurred. Status Code : -88700"

If I ignore the error and try to acquire samples, I get a blue screen of death and the PC reboots.

DAQmx Error: An internal error occurred.
Task Name: MyTaskCI
Status Code: -88700

I tried unreserving the task, and setting the sampling timing type back to on demand, with input buffer size to 0 (also tried 1, and 1000, neither worked). I noticed that going to sample clocked mode changed various properties. I tried manually setting the data transfer mechanism back to programmed io, and disabling CI memory mapping but that did not help. Additionally I tried setting the sampling mode to finite, and number of samples per channel to 1 but that didn't help either. I also tried setting the sample clock source back to blank, but that didn't help. I am not sure if there's something else I am missing. I tried reading all the properties I thought might be getting changed by sample clocked mode, and re-applying them - but that didn't work either.

Please find attached a simplified peice of code (adapted from the NIDAQmx ANSI C Example program: ContAcq-IntClk-EveryNSamplesEvent.c) to reproduce the issue.

Your feedback is greatly appreciated.

Thanks,

   hemdanw

   The MathWorks

[Efrain_G]

Dear hemdanw

After doing some research, I found that apparently it is a known issue in DAQmx 9.1 the fact that reconfiguring a task from sample clocked to on demand will throw that error.

I would suggest you to install a later version of DAQmx. Hopefully, that will take care of this problem.

[soeren]

Hi whemdan

Looks like I'm having the same problem as you. I used to stop and clear the tasks to switch between "On Demand" and "Finite" mode. But sometimes that gives me glichtes in the readings, so I also tried moving around with some of the DAQmx Timing and Triggering properties, wihout any luck. The easiest solutions is probably to just instead of running it in "On Demand" mode, to reduced the number of samples to 2............but that's not a proper solution! That's just junk coding!

I'm using a PCIe-6259 on a realtime system, I put up a similar thread : https://forums.ni.com/t5/Multifunction-DAQ/Error-200262-Swtiching-between-quot-On-Demand-quot-and-qu...

I'm using DAQmx 8.9.5, and pretty much tried the same solutions you tried out with out any luck. Sometimes Labview just breaks completely down after too many "Internal Errors"

Let me know if you make it work, it's the last hurdle before my GIANT program runs smoothly.

I would think that NI should be able to comment on wheter it is possible to switch between these two fairly simple ways of acquiring data?

[Jim_S]

Hello Whemdan,

After looking over your code, I am not completely sure when the error occurs. Is it right after DAQmxSetSampTimingType(taskHandleCI, SampleTimingType) where SampleTimingType is OnDemand? When you unreserve the task and try to change the timing the error still occurs with the blue screen?

I have found another customer who was having a similar issue switching between Ondemand to hardware timed. In his case, he switched from Hardware-timed (Continous Acquistion or Finite) to On Demand and back to Hardware-timed which would produce this error but wouldn't cause the machine to blue screen. We have been able to reproduce this here so R&D is looking into it. Unfortunately, this issue is a CAR in the DAQmx driver under 242128 that has not been fixed yet.

In order to avoid this problem, can you explain why you are switching the timing back and forth? I saw in the code that you are trying to show the user that everything is working. This could be done by performing a self-test or reset programmatically. Would this work instead?

[comrade]

I seem to have run into a similar problem in wanting to trigger a digital output using Change Detection on DAQmx Timing.vi (see attached VI).

SysConfig:

WinXP SP3

LabVIEW 8.5.1

DAQ-mx 9.2.2

simulated cDAQ-9172 configured as shown on the FP of the attached VI

This setup gets me error -88700 in the first "DAQmx Start Task.vi" (the lower one in th BD), where there seems to be hardly any explanation for this error number.

I have requested a similar functionality with the German NI team in Munich, discussed in SRQ 909484 - this didn't bring me the desired functionality as well and I come close to the assumption here that hardware-based triggering of digital outputs using digital inputs just doesn't work with USB-based C modules...

Any new leads in this matter?

Thanks a bunch.

Falk Schneider

Inpro GmbH, Berlin, Germany

[Brad_K]

Hi Falk,

Enabling change detection timing for digital output tasks does not seem to be supported on the cDAQ-9172. However, you have found a bug: the high-level code used by the cDAQ-9172 (and M Series) to check whether the task's settings are valid did not catch this and return a helpful error, so some lower-level code ended up returning an internal error. This error handling bug has been reported to R&D as CAR #280166. (Note that running the same VI on a cDAQ-9174/78/88 or an X Series will return error -200452, "Specified property is not supported... ChangeDetect.DI.RisingEdgePhysicalChans", which points in the correct direction.)

I think it's possible to do what you want. Try running the shipping examples "Read Dig Chan-Change Detection.vi" and "Write Dig Chan-Ext Clk.vi" at the same time, with the clock source for the second VI set to "/cDAQ1/ChangeDetectionEvent". Note that the digital input task will only return data when a change occurs. If you want to read the digital inputs independently of the change detection, you may need to create a second digital input task with the DI.Tristate property set to false (allowing the second task to snoop on the lines).

Brad

[comrade]

Thanks for the quick answer, Brad. I appreciate it 🙂

I will have a go on the suggested plan of yours and be back either way to tell about the success or ask for more advice

regards

Falk

[comrade]

Hi,

after having tried this and that with the suggestions you made I seem to have to come to the conclusion that the proposed way doesn't provide for the desired functionality. This is for several reasons:

1. None of the two examples mentioned "waits" for the other at any point in order to complete its action - they run totally independent. This of course may be because of the choices I made with the channels - I admit I am a bit confused, which channel is supposed to trigger which one here...
2. The way you describe it, the digital input should wait for the change on the output to occur - actually I want it the other way around: Suppose I connect a button to the digital input an I want the output to be triggered when I press the button. This is basically the functionality I crave to receive.

Could you please give me the correct values for the respective channels and terminals in both VIs when using the following modules:

SLOT1: NI9472 (DO)

SLOT2: NI9421 (DI)

for your proposal to work as intended. Thank you.

In case the rising and/or falling edge terminals in the "read dig chan...vi" should correspond with the DO-module in the "write dig chan...vi" there will be a conflict since the VI reserving the terminals first will block the usage for the other VI. I have the feeling my understanding of the way the hardware works is incomplete or not thorough enough.

Regards

Falk

[Brad_K]

Hi Falk,

Change detection does two things:

• Reads digital input channels when a change occurs on a set of digital input lines.
• Optionally provides a (non-periodic) trigger or clock for another task, such as digital output, analog input, analog output, or counters.

This secondary functionality is only useful when you want to detect changes on multiple input lines and treat them as if they are the same, or if you want the input lines to be sensitive to both rising and falling edges. Since you only want your digital output task to look at rising edges on a single line, you can use a PFI line instead of using change detection. The cDAQ-9172 supports PFI lines in slots 5 and 6, so move the NI 9421 to slot 5 or 6.

> Suppose I connect a button to the digital input an I want the output to be triggered when I press the button.

Okay, that partially explains what you're trying to do. How many samples do you want to output when the button is pressed?

• If you want each button press to output one sample, then run "Write Dig Chan-Ext Clk.vi" with "Physical Channels" set to "cDAQ1Mod1/port0/line0:7" and "Clock Source" set to "/cDAQ1Mod5/PFI0" (with the NI 9421 in slot 5). Every time you press the button, the output will change once, assuming that the button is debounced.
• If you want each button press to output a waveform containing many samples, then ideally you would be able to run "Write Dig Chan-Int Clk-Dig Start.vi", but this uses DIO triggering functionality that isn't supported by the cDAQ-9172. To emulate this functionality on the cDAQ-9172, you would need a combination of "Gen Dig Pulse-Finite-Dig Start.vi" and "Write Dig Chan-Ext Clk.vi". Start the DO task first because it will wait for the sample clock.

If the button is not debounced, you may also want to enable digital filtering on PFI0 (or build a debounce circuit). I don't know of a good example showing how to do this. Maybe someone else has an example to recommend?

Brad

[comrade]

just a quick drop in - I am currently waiting for a cDAQ to arrive so I can test with REAL equipment rather than with simulated devices. Thanks for your help anyway, Brad 😉

I'll get back here as soon as I have completed the tests.