Incorrect DI readings with change detection events and USB-6229

[Timmar]

Simon,

I understand your suggestion but it would require that I duplicate my hardware (PXI Cards don't come Cheap) adding an oncost to each my systems of around $750, so.. No, not an option.  I would Revert back to the original Polled system and pay for it with a balance between latency and cpu overhead.

I am working with a 6521 and a 6280

6521 doesn't support data transfer mechanism property, 6280 won't work without it.

I am going to have to write some cunning code to detect the type and decide which method to use.

Tim L.

[Kevin_Price]

Timmar,

Here's a trick you can use *after* the first change has been detected.  For initial state, you may still have to do the little dance where you first query the digital states in an unbuffered task, then reprogram for a buffered change-detection task. 

Since you are normally reading all available, here's the special code to call to see the current state.  It actually reads the most recently buffered state, but since that represents the last change the current state should still be the same.

I've used this kind of construct a lot for other data acq tasks where I just need a snapshot of

recent data.  (You may need to use a diff version of DAQmx read to match your port size or

channel config in case you're using bool arrays, dig waveforms).

-Kevin P

[Timmar]

Kevin,

This is a masterpiece, Most impressive

I have Given you a Kudos for finding a way to do that,

Not quite a solution, but impressive none the least.

I am going to keep this in my amory for just such an occasion.

At this point I am doing a standard, asynchronus read during task setup, this gets me 9/10ths of the way there.

I am still exposed if there is a change between my pre-sample and program "Main" starts.

If only there was a way to force/trigger this..........

Tim L

[Timmar]

What about a device reset?

[mike-o-tronic]

Hi folks,

I’m working with a PCI-6229 card and was running into same issues. I’ve three digital inputs, where I can toggle one easily. The other ones are connected to relays, which I don’t want to switch around too much.

I tested different approaches and was able to reconstruct the issue, that there were more samples acquired than events generated.
My intention was basically to react on input change with sending a message to another actor (using the actor framework). So I want to ignore bouncing inputs and just need the actual state. For this I basically do what Kevin said: “don't just read 1 sample”. I read multiple samples, until I have the last one. So far it seems to be working pretty well for me.

A small note:
The two other inputs I wasn’t toggling that much are by default one high and one low. I recognized that the low input was floating while I was toggling my test input. But this might be a ground issue with the external system. Don’t know how this is set up.