How Do I Handle MULTIPLE Digital Change Detection Events In LabVIEW using dynamic events in an event structure?

[MAILFERTSeb]

Dear all,

I'm trying to handle DAQmx events on an event structure.

Following previous posts (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000004AvPSAU&l=fr-FR), what I did with success is to monitor rising edge on a digital input which generates an event.

Now, I want to monitor two or more digital input lines (lines 23, 25 and 27 in my example). How can I get the name or the reference of a specific digital line?

Thank you for your hep.

Best regards.

Sébastien

[Kevin_Price]

Ok, a bunch of things, so let's go step by step.

1. When you initially create your task in the call to DAQmx Create Virtual Channel, there's an input for 'line grouping' that you left unwired.  I would advocate that you declare this explicitly so you don't have to remember the default or count on it never changing.

    It will probably be simplest for you to choose the non-default 'one channel for each line' option.   With 3 digital lines in your task, it will be considered to have 3 digital channels of 1 line each.

2. You call DAQmx Timing for Continuous Sampling.  That will create a task buffer.  You'll get some default size since you didn't wire the input 'samples per channel'.  Creating a constant from the terminal suggests this might be 1000 samples.

3. You register for a "DAQmx Signal Event" of "Change Detection" type.so you can get notified of rising edges on any of your digital lines via an application-level software event.  I'm being careful with terms here because there is a related, but *distinct*, hardware-level change detection event that be routed around as a hardware timing signal.

   I'm also going to be a little cautious about these 2 distinct things.

4. I happen to know from some work well over a decade ago that there's a max possible rate for hardware-level change detection events to be fired.  As I recall, it might have been somewhere in the 5 MHz realm on the hardware I was using.  I had a test system where several digital lines that should *nominally* transition at the same time would actually have transitions about 100 nanosec apart or so.

   Consequently, I might have a fast ripple of 3 actual transitions that only produced 1 hardware-level change detection event.  I had to code differently as a result because I wouldn't necessarily be buffering up a distinct sample for each individual transition.

5. I can't speak from experience about the application-level change detection events, but I would be suspicious that they might *also* have some limit on their firing rate.  I would certainly look to test it out rigorously rather than make assumptions.

6. And so because of all that, the way you read and process your digital data inside your event case might need some special consideration.

7. Most importantly, I wouldn't count on being able to DAQmx Read 1 single sample for each application-level event and be *certain* I was keeping up with the latest hardware-level samples.  Instead, I'd ask for multiple samples, feed in the magic number -1 which means "give me all the samples in the buffer now", and work from there.

    Somewhere between usually and always, you'll only get 1 sample back.  I'm just not certain that you can count on it always being 1 and only 1.

8. When you do call DAQmx Read, what you get back is the *state* of your digital lines *after* the transition that caused the change detect event.  To know which line(s) had a transition, you'd have to retain and compare the end state you got from your previous call to DAQmx Read.

    This can be a problem at startup because the 1st sample tells you the state *after* the first change, leaving you blind to the initial state.

-Kevin P

[mcduff]

@MAILFERTSeb wrote:

Now, I want to monitor two or more digital input lines (lines 23, 25 and 27 in my example). How can I get the name or the reference of a specific digital line?

I can't see your code due to I haven't update to 2020 yet. But you should be able to read multiple lines.

On the left edge of your event structure, expand the node so you get the CtlRef; this is actually the DAQmx task. Use that node to read the digital lines. You should be able to tell which one fired. In the picture below I check the 0 and 3 line to see if either is true.

mcduff

[Kevin_Price · Accepted solution]

I'm going to add some clarifying comments to mcduff's post for the sake of the OP.

His example is a little different than the approach I described.

• he's treating all digital lines as a single channel.  The data comes back as an unsigned int.  The specific lines are inspected via bit-masking operations.  All this stuff is dependent on knowing:
  1. the width of port 0 on your device, so you know whether to use the U8, U16, or U32 version of the Read function.
  2. the exact lines that were originally configured in the task in order to form the right bit-masking calculations.  Often, many of the bits returned represent lines that weren't in the task.  Their values will be meaningless and need to be ignored, thus you need to know which bits matter and which don't.
• I tend to prefer to treat each digital line as its own distinct channel.  And then I generally call the version of DAQmx Read that gives me an array of Booleans. 
  1. This method doesn't need to know or care about the width of port 0.  The array will simply be as long as the # of channels that were configured.
  2. Boolean data is only returned for lines configured as part of the task.  None of it is meaningless.  Some apps still may require that you know which array index corresponds to which digital line, such as any decision logic based on individual states or transitions.
• He's reading just 1 sample.  It's quite possible mcduff knows something I don't and has good reason to think the 1-to-1 correspondence I worried about will in fact be reliable.  I'll let him speak to that, I may be learning some good new stuff.
• Technically, he's only checking for whether bits 0 and 3 are in the high state after whatever transition fired off an event.  This code alone won't tell you which one just changed.

All that said, here's what some corresponding code might look like if you approach things the way I described earlier:

(Note: my memory failed me.  I thought there was a version of multi-sample, multi-channel version of DAQmx Read that would return a 2D Boolean much like the 2D Double for AI.  I don't know if it's a correct memory of an obsolete function or an altogether incorrect memory.  Either way, I put together the code needed to end up with a 2D Boolean array.  I've gotta say, it's kinda ugly.  Partly because I'm doing a little more stuff, but partly the approach and method itself.

   Code might look simpler using a a 1D array of Digital Waveforms, but I've never warmed up to the Digital Waveform and have pretty much only used them for graphing.  Your mileage may vary.)

Note further that my array indices 0 & 3 wouldn't necessarily reference the same lines as his bits 0 & 3.  His bits would always map to specific lines in the hardware port.  My index mapping would depend on which lines were configured to be in the task and in what order.

   Going back to the OP's hardware description, you'd need to do masking on bit #'s 23,25,27 after a U32 read using mcduff's approach.  You'd need to know the digital line correspondence for array indices 0,1,2 using my approach.

And I just thought of another subtle problem with my approach.  If application event-handling gets bogged down, there may be additional application-level "change detect" events pending in the queue when one gets handled.   In my approach, I read all samples available *at the time I call DAQmx Read*, which may include data corresponding to change detect events I haven't received and dealt with yet.

   No more time now, but wanted to give you the warning and food for thought.

-Kevin P

[mcduff]

---

---

As always @Kevin_Price  gives an excellent answer.

My experience with DAQmx Digital Events is limited. I used them to see when interlocks were triggered on a laser system. So the events were well defined and typically slow and not in rapid succession. My guess is that events that are "missed" aren't really missed, they get added to the event queue, you just have a delay in processing them. My case was really an UI and state transition event. The laser was controlled by hardware interlocks, I just wanted to know when they fired, alert the user, update the UI, my state machine, etc. For this case they were extremely useful.

As far as choosing lines over an array of booleans, I haven't thought about it as deeply as @Kevin_Price. It was mostly personal preference. I prefer the fact that I can do boolean operations on numbers; I can AND the result with number and check if it's not zero. If so, then I know a line is true, no array indexing, no searching an array, etc. Just personal preference.

mcduff