12-03-2014 01:13 PM
I set up a digital I/O event per the attached diagram so that I can collect data from our custom hardware. This event fires when there is data on the 16 bit "bus" on ports 2 and 3 of my PCIe-6509 (96 bit DIO card). The 'data in ready' line is on port 4, line 1. When this line goes high, I get an event and queue a message to the bus reader (on the broken wire). Depending on the data on the bus, I may get two events, causing a double read. If I place 0x8F or 0xCF (among others) on the bus, it works fine. If I place 0xFF or 0x9F (among others) on the bus, my event case runs twice, placing a second copy of the data on bus into my buffer. The 2nd event occurs around 1ms later.
The data is placed on the bus. Then the 'data in ready' line is brought high for 10ms after which it is returned to low. The data remains on the bus.
Examining the signals indicates that the custom hardware is working properly.
The event trigger is set for rising edge. The problem persists if I change to trigger on the falling edge.
The unused pins on the SCB-100 are left unconnected. The 6509 lines are configured as tri-state with pull-down.
Windows 7
LV 13 SP1
DAQmx 9.8
What could be causing this?
12-04-2014 06:04 PM
Hi Les__Bartel,
Have you confirmed that the event is triggering twice? I would run this in highlight execution to confirm that this is the case. I don’t know if there’s any potential that another part of your code could be causing this, but it will be helpful to take a look.
Can you also clarify your hardware connections? How are you bringing the ‘data in ready’ line high for 10ms?
I’m also interested to see the rest of your code to see what else is going on.
12-05-2014 07:50 AM
Attached is the VI I'm using to send data to my application (Main2.vi). This VI is meant to emulate a piece of hardware which is not yet complete. It loads a data word on the bus and then strobes the 'data in ready' line. For the test data in the MCB Frame, it strobes the 'data in ready' line twice. I verified this with an oscilloscope. I zoom in on the waveform and see a rise time of about 50us. There are no spurrious transistions anywhere, just two very clean pulses. Main2 is running on a computer with a USB-6008 DIO device. If I send the two words 0xFF and 0x1, I get 3 events. If I send the two words 0xFF and 0xFF, I get 2 events. Depending on the values for the first and 2nd words, I may get two or three events as indicated by the 'appended array' indicator. (I wired this indicator this way so that I could right click and empty the array while the VI is running.)
Reader.vi is running on another computer with a PCIe-6509. I have the two DIO devices wired together as shown in the DAQmx create channel VIs.
I can enter several more words in the MCB Frame. Any time a 0xFF appears in the frame, two events are generated. Again, there are other values which generate two events, 0xFF is not particularly special. The timing of the event is such that the data item following the 0xFF is duplicated in my receive buffer. This makes it quite puzzling for me.
Turning on execution highlighting causes the software to miss bus data.
Perhaps I'm not setting up my event registration properly?
12-07-2014
11:31 PM
- last edited on
06-04-2025
08:27 AM
by
Content Cleaner
Les_Bartel,
I’m still a little unclear of how the two VIs communicate with one another. Can you explain a little more how Main2.vi is strobing the ‘data in ready’ line?
I found some online resources that may be helpful. One is an example on how to register an event with DAQmx change detection and the other is an overview of digital change detection using DAQmx.
Change Detection in NI-DAQmx:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAn9SAG&l=en-US
You may want to take a look at your timing VI in reader.vi. I’ll pull an excerpt from the bottom link that explains how the rising/falling edge terminals function:
“[The] LabVIEW program continuously monitors a change on the rising and falling edge of some digital lines. When a change is detected, the values on the digital lines are read or latched into memory”
So when the lines you wire into the falling/rising edge terminals change value, they will cause the lines specified in the task to be written to the buffer. In your case port 4, line 1 is wired into the rising (falling) edge terminal for itself so the value of itself is being written into memory. Is that what you were intending?
12-08-2014 07:42 AM
In Main2.vi: the first DAQmx VI places the data on my bus. The second DAQmx VI turns on the 'data in ready' line. The third DAQmx VI turns off the 'data in ready' line after 10ms. The 'data in ready' line is monitored in reader.VI.
When I run the VI in your first link using my Main2.vi to change the DIO lines, I get the same behavior as my program. When the 'lines to monitor' is connected to both the rising and falling inputs, it registers 5 events when I run my Main2.vi with 2 words (0xFF and 0x1 - first case) in the MCB Frame. If I change the 0x1 to 0xFF (second case), I get 4 events. If I disconnect the input to the falling edge input, I get 3 events for the first case and 2 events for the 2nd case. Out of laziness, I configured the Digital Input Lines on the sample VI to read port0:line0.
Your example did not have the buffer config VI, so I removed it from my VI. I continue to get the same behavior.