Incorrect DI readings with change detection events and USB-6229

[JSwing]

I'm using LV 2009 SP1 with Windows Vista, and a USB-6229.

My application is using change detection to monitor 3 digital switches.  Modifying the example "Digital Change Notification.vi", the application does not read the sensor states reliably. 

After creating the task, I read the initial state into the shift register, set up the change detection event, and then start the task.  In the event of a digital change, the state is read and stored in the shift register.  In the event of a timeout, the value in the shift register is fed to the indicator.  At some point, (I think when the transitions happen too fast), the DAQmx read starts to return incorrect values.  In the front panel shown, the read should be 001 as apposed to the 110 shown.  If I stop and start the VI, the initial reading is correct.

What am I missing in order to get the correct values?  

thanks,

-Jeff

Message Edited by Jeffrey Swing on 06-10-2010 09:06 AM

[JSwing]

I found that by using the DAQmx property node, that the AvailSampPerChan increases from 0 during a series of fast transitions.  The DAQmx read then gets behind and never catches up to the current state.  It is as if the event structure is not reacting to each state transition.  It only takes the AvailSampPerChan to get behind by one sample to create problems.

Any ideas on how to keep the event structure from dropping these events?  I thought that these were queued and should all be dealt with by the VI in turn.

thanks,

-Jeff

[Ryan_T]

Hi JeffreyS,

I have taken a look at the screenshot that you have provided and I am not sure why you are using the event structure.  Can you provide me with more information on your end goal so that I can understand the use and idea behind the event structure?  Also, can you provide some information on why you modified the example because that will help me understand the issue better?

Thanks

[JSwing]

Ryan,

I have an existing control application that reads/writes from many analog, digital, and timer channels, running in a software timed loop with a period of 100ms.   Changes were made to some of the actuators and the mechanisms.  I need a faster response to changes on specific digital channels, on the order of 0 to 5 milliseconds.  I have some room to turn the period down to 50 ms, but it doesn't take me far enough.

To enable change detection on these specific channels, I created a parallel while loop similar to the example.   The event-driven read then drives changes to some of the digital outputs, and then stores the new data in a global variable accessible by the timed loop.   This gave me the desired quick response time with minimal impact to the timed loop.  However, I noticed that the state of the digital lines got behind. 

I went with the event structure as the application may be sitting idle for variable amounts of time, I could not easily stop the application if I used a DAQmx read with an infinite timeout.

Rather than debug the entire control application, I was able to isolate/recreate the problem by modifying the change detection example.  I'm guessing that another change detection event happens before the software is done responding to the previous one.  The event structure appears to be ignoring the subsequent change event, so the follow up read never happens.

I hope this makes things clearer.

Thanks,

-Jeff

[stilly32]

Hey Jeff,

Is the event structure ignoring events, or are they just happening too fast for the UI to update? You may be running into a DAQmx behavior, where DIO transfers are grouped into chunks of 4 bytes (32 bits). If you're reading less that 8 lines, these means DAQmx will queue up 4 samples before transferring from the device. The four samples seem to arrive in the PC buffer at the same time, so the DAQmx event is fired off 4 times in rapid succession.

If you just put a counter in the event case to see how many times it is called, this should show you if you're running into that behavior. Highlight execution would also show it off. Also, if you read all 32 lines and the behavior changes, this would be another indication.

Hope this helps,

Andrew S

Message Edited by stilly32 on 06-14-2010 09:39 AM

[JSwing]

Andrew,

Thanks for the feedback.  I don't think it's the 4 byte issue.  Reads happen for just single state transitions (one sample).  I tried watching all 32 channels on port0 with the same results. 

It looks like either events are not being generated, or the structure is ignoring them (too fast).   I created a counter in the event loop for the "<task out>: Signal" case.  I also read the DAQmx read property node value "TotalSampPerChanAcquired".  Initially, these two counters match with slow changes in the digital states.  However, if the digital transitions happen too close together, the event counter will be less than the total samples acquired value.  The lag will get worse as more fast transitions happen.  The reads will always be behind and never catch up unless I restart the VI.

-Jeff

[JSwing]

I am able to get the VI to do what I want if I don't use the event structure and set up the DI with change detection and have a DAQmx read inside a while loop.  But I can't stop the DAQmx read if I have it wait indefinitely (timeout = -1), it requires another change of state or a force quit.  If there was a way to cancel the read, then this method would be sufficient.

-Jeff

[Timmar]

I would like to jump in here and say that I can replicate Jeff's problem and it is causing me distress also.

I am surprised that this wasn't looked into further, in my opion it reeks of being a bug in one of the subsystems..

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.

The last reading does not match the resting state of the switch.  It appears that some date is being lost somewhere along the way.

Is there a limit on the total number of unprocessed events that can generated?

PXI-6289 in realtime

[Kevin_Price]

I don't have change-detect hardware handy for testing ideas out, but here are some thoughts off the cuff:

1. I suspect that one main issue may be that the change detection hardware signals on the board can respond to and buffer up samples at a much higher rate than change detection *WINDOWS* events can be generated.  Perhaps a fast burst of 5 digital transitions only produces 1 or 2 windows events for example.

2. However, the task buffer will store up 5 digital state values even though only 1 or 2 windows events get queued.

3. Thus when you read a single sample in default fashion in response to a windows event, you are sometimes looking at *past* states rather than *present* states.

4. So now what?  Well, don't just read 1 sample when responding to the Windows event.  You can instead do a multisample read, using the magic # -1 to specify that you want "all available samples" from a continuous sampling task.  Then you can just ignore all but the last sample in the array which should represent the final steady state value.

5. Caveat: it's conceivable to me that under rare circumstances, there might be a long rapid burst of transitions, and that a couple transitions occur after the final windows event is fired *and* after the DAQmx Read is called in response to that windows event.  Perhaps your timeout case should query for # available samples so you can do a makeup Read if that ever happens?

-Kevin P

[Timmar]

I have spent many hours tinkering and tampering trying to get this to work

Here are my findings:

Ther property node "Don't overwrite samples" appers to give mild improvement. This is emperical observation only

If you try to read without a change, the vi waits until there is one or a timeout occurs.

In normal function it generates 1 event for each change event, Data is LATCHED on change into the waveform buffer.

Time stamp accuracy is sketchy at best but accurate enough for my purposes. It is not uncommon to get multiple transitions marked with the same milisecond time.

So the get all function works,

The catch, if you have 125 change events and read all samples on the first event. You then get 124 events with no samples associated with them. Each one requiring processing

The times appear to be ok.

There are many and varied methods all work just fine with a slow changing waveform.  Bravo.

Add a noisy signal with narrow transitions such as a switch debounce and it is possible to observe an inversion anomoly.

somehow the samples and events get out of sync, I have created a test vi (Wiring port 0 to 7 Do to DI) to simulate the faults.

[Note to the critics: This vi is for proof of concept and i used autocleanup, it is an absolute mess, I know]

There are some special functions in there to ensure synthesys doesn't start until the event processor is ready and synthesys has time to finish before the event processor is closed.

I have given up and am going to plan B: Synchronus acquisition with signal processing edge detection.