PhysicalChannel.DIChangeDetectionSupported not correct

[Holland]

Hello,

I have a PCIe-6321 with 24 digital lines. According to the specs only the first 8 (port0/line0..7) can be used for change detection. Also when I try to use ...

myTask.Timing.ConfigureChangeDetection(rising, falling,

SampleQuantityMode.ContinuousSamples);

... on channels not supporting change detection (port1 and port2) I get an expected error on verification.

In my program the user can select which terminal to use. I feed the user a list of all DILines which have the the PhysicalChannel.DIChangeDetectionSupported set to true, like this ...

PhysicalChannel physicalChannel = DaqSystem.Local.LoadPhysicalChannel("\dev1\port1\line5");

if (physicalChannel.DIChangeDetectionSupported)

{

    inputTerminals.Add(("\dev1\port1\line5");

}

However all 24 digital lines return true on PhysicalChannel.DIChangeDetectionSupported which should not be the case.

Is this a bug or am I missing something?

[Brad_K · Accepted solution]

Hi Holland,

I think it's a bug, but it's also sort of a grey area. Here's the description of that property from the LabVIEW help (I assume that the .NET help says the same thing): "Indicates if the change detection timing type is supported for the digital input physical channel."

Can you use the change detection timing type with port1 or port2? In normal usage, the answer is no. However, there is one case where you can: non-buffered change detection. If you set the input buffer size to 0, then it is possible to have lines from port1 and port2 in the task without getting errors, as long as they aren't included in the rising/falling edge lines properties. (In other words, port1 and port2 can't drive the change detection task, but when buffering is turned off, they can come along for the ride.) DI.ChangeDetectSupported returning true may be technically correct, but it's not particularly helpful because you have to configure more properties to make it work.

M Series also supports non-buffered change detection, and it returns false for DI.ChangeDetectSupported on port1 and port2. So whatever the correct behavior is, this property is not behaving consistently on M Series vs. X Series. I just filed a corrective action request, CAR #298171.

As a workaround, if your code doesn't have to work on NI 65xx devices, perhaps you could use DI.ChangeDetectSupported && DI.SampClkSupported? DI.SampClkSupported returns false for port1 and port2 on both M Series and X Series.

Brad

[Holland]

Hi Brad,

Your workaround gives us the correct behaviour and is sufficient for our application. Thank you very much for that!

Kind regards ...

[Brad_K]

Correction to my previous post: unlike M Series, X Series can detect changes on port1 and port2. However, it still doesn't support buffering on port1 and port2.

What was the actual error you received? I just tried it, and the error doesn't say I can't use change detection on that port:

"Error -201062 occurred at DAQmx Start Task.vi:1

Possible reason(s):

Selected lines do not support buffered operations.

Ensure only lines that support buffered operations are being used in the task. If using change detection, the task must be changed to non-buffered hardware timed single point to support these lines.

Device: Dev2
Physical Channel: port2/line0

Task Name: _unnamedTask<0>"

Setting the buffer size to 0 prevents this error.

Brad

[Holland]

I checked it and that is the actual error it returns. However when I change it to non-buffered change detection I get a different error.

I changed Task.Timing.ConfigureChangeDetection(....., SampleQuantityMode.ContinuousSamples) to Task.Timing.ConfigureChangeDetection(....., SampleQuantityMode.HardwareTimedSinglepoint).

When I include lines from port 1 or 2 in the rising or falling I get the following error on the line Task.DigitalChangeDetection += new DigitalChangeDetectionEventHandler(....).

DAQmx Signal Events are not supported by your device. DAQmx Signal Events include the Hardware Timed Counter Output event, the Sample Complete event, the Sample Clock event and the Digital Change Detection event.

I hope this helps.

Kind regards.

[Brad_K]

Hi Holland,

Sorry, the error message is misleading. Non-buffered change detection is supported for port0, port1, and port2 on X Series, but hardware-timed single point is not supported on port1 or port2. The former is mostly useful for DIO ports that don't support waveform DIO; the latter is for low-latency real-time control loops and requires waveform DIO. I filed CAR #298660 to our documentation team about fixing the error message and adding documentation about non-buffered change detection.

Here is how to enable non-buffered change detection:

myTask.Timing.ConfigureChangeDetection(..., SampleQuantityMode.ContinuousSamples);

myTask.Stream.Buffer.InputBufferSize = 0;

Brad

[Holland]

Hi Brad,

It seems that setting the InputBufferSize to zero only works for port1 and port2 (I have not actually tested this because I didn't had enough time to change the electrics). When using port0 I don't get any events. Maybe that is by design? If so than there is no possibility to mix signals from port0 and port1/port2.

Kind regards...

[Brad_K]

Hi Holland,

Sorry, no, this is not by design. It appears that as of NI-DAQmx 9.3, change detection events only work with buffered tasks (and thus only with port0, when buffer size != 0). For non-buffered tasks, you can read changes with DAQmx Read (which will wait for the next change), but registering for the event causes timeout errors and doesn't produce any events. We'll look into why it's not working (CAR #299441), but for now you'll have to work around it by not using port1 and port2 for change detection events. Back to your original question, I think DI.ChangeDetectSupported && (ProductCategory != XSeries || DI.SampClkSupported) is the way to go.

Brad

[Holland]

Hi Brad,

Thanks so much for your help. To be sure if I understand it correctly:

1. Port0 supports buffered and not-buffered tasks;
2. Port1 and Port2 only support not-buffered tasks;
3. Change detection only works on buffered tasks, but should work on non-buffered tasks also.

I'll use port0 only by using the proposed DI.SampleClkSupported workaround. It's not a problem for us but I always try to write my software operator proof.

[Brad_K]

Hi Holland,

That's almost it:

1. Port0 supports buffered and not-buffered tasks;
2. Port1 and Port2 only support not-buffered tasks;
3. Change detection timing (i.e. Task.Timing.ConfigureChangeDetection) works on buffered and non-buffered tasks.
4. Change detection events (i.e. Task.DigitalChangeDetection) only work on buffered tasks, but should work on non-buffered tasks also.

Brad