Incorrect DI readings with change detection events and USB-6229

[John_P1]

Hi Timmar,

"I have a noisy switch and am using change detection to measure the time of the first and last edges of the contact bounce and then using it's final acquisition to determine the input state."

I'd suggest doing this instead:

The concern would be that the counter FIFO might overflow if your transitions occur too quickly as it is only 2 samples on your PXI-6289.  If this is the case, I can think of another way that uses digital filtering that I think would also work but I need to test it out.  X Series devices would also work since they have a larger FIFO (but the first sample is thrown away on X Series, so you would need to account for this differently).  If the transition can take longer than 100 ms,  increase the amount of time to wait before reading back the counter samples.

If you don't want to poll for available samples, you could alternatively use the Every N Samples event, but the above method seemed a bit more straightforward to implement.

Best Regards,

[John_P1]

Jeff,

It is indeed possible for hardware events to be generated faster than the sotware events like Kevin mentioned (especially on USB).  So, what's happening with your existing architecture is your software is falling behind the hardware when producing events at higher rates.

If you do want to continue using the change detection event in software, perhaps include a timeout case in the event structure that polls for the available samples and then reads them back in so the software can catch back up to the hardware if it falls behind during a burst of change detection events.

Best Regards,

[Timmar]

Thanks john,

I have many solutions to the problem, only a few are actualy applicable

My application requires that an output follows an input with a specified delay.

The application is on LV realtime so front panel user events are not supported, I need to poll them.

The change event implimentation sounded perfect, unfortunately, it appears that somewhere between Labview, Daqmx and the hardware one of the subsystems are broken.

I haven't posted here looking for a workaround (yet).

I was hoping that someone could explain the cause of the problem and feedback to NI,

Best outcome for me would be an updated daqmx driver.

Tim L

[John_P1]

Hi Tim,

My earlier post isn't a workaround per se, but rather a better way to measure the time between the first and last edges of the contact bounce, which is what you had asked about.  In the above method, the measurement is taken at 50 ppm accuracy with the resolution of the timebase (1/80 MHz = 12.5 ns).  Using change detection to make the measurement you are asking relies on the OS for timing, which even on an RT OS doesn't give you the same performance.

If you need an output to follow after a speified delay after the switch has settled, I would look into using digital filtering.  The signal will be passed through after it has remained stable for a specified amount of time, which you could then trigger your output off of.  If you arm a counter off of the raw input signal, count a timebase, and sample the count register off of the filtered signal, you can tell how long it takes for the switch to stop bouncing.  Keep in mind that digital filtering would add 25 ns of jitter using the 6.425 us setting.  If the bounces are slower than that, the added jitter might be too high (20 us on the 2.56 ms setting).

The limitation it sounds like you are running into is that the OS cannot queue events quickly enough to keep up with the speed that you are generating them.  You might be able to get the performance you are looking for using Hardware-Timed Single Point with Change Detection, but this is only available on X Series devices.  Either way, the counter method should be a better alternative so I'd recommend using that instead of change detection.  If you were to switch to X Series anyway, you would have more options with the digital filtering, as well as an on-board counter FIFO to prevent overwrites.

Best Regards,

[Timmar]

It has been a while, I think I have solved this one!

I found an appnote:

DMA vs Interrupt

Thought I should post this for future travellers.

Also,

I am looking for a method to read the state of a port on request.

Any Suggestions?

Tim L.

[Izzzzz]

Hello Timmar,

Could you clarify what you mean "I am looking for a method to read the state of a port on request."  Are you looking for a function such as the 'DAQmx is Task Done' function to inform you if the task is done executing?

Regards, 

Izzy O. 

Applications Engineer 

National Instruments 

[Timmar]

Izzy,

The "On Change" method of data acquisition only allows data to be acquired when there is a change,

i would like to be able to read the port lines "On Demand" without closing and re-opening the task.

A simple example is on powerup I need to read the states of all of the inputs.

This can be acheved by doing a Read prior to configuring the timer, unfortunately, there is up to 10 seconds before I have registerd for the event and will start processing changes.

I would like a method to do a "Spot Read" using the on demand task.

Tim L.

[Simon-P]

Greetings, Timmar;

Would something like the Read I/O Port VI be of use in this case? It may be used to check the state of the signals connected to an input port.

http://zone.ni.com/reference/en-XX/help/372134F-01/ni-motion_vi_help/read_i_o_port/

Cordially,

Simon Perez

[Timmar]

Simon,

This appears to have a very limited range of supported devices

The functionality that I want to work is shown in my example (The red box that says fail!)

Once the timer has been configured, data can only be acquired after a change.

What I am looking for is something to trigger a read even if there is no change or event publish the current port state on "start"

[Simon-P]

Greetings, Timmar

Would you be able to internallty route it into a different line and read that in a completely separate task? I will look into it a bit more in my side as well to see as to whether it would be possible.

Cordially, 

Perez, Simon