DIO Port Oddity

[GeoffF]

Hello all,

Development Platform: 32-bit Windows 7, LV2012 Professional Development System.

Production Platforms: Windows XP.

We're running a test application that uses PCI DIO cards, specifically an NI PCI-DIO-96. (Actually, on one system there are two PCI-DIO-96 cards and the other has a PCI-DIO-96 and a PCI-DIO-24, but it's only the 96 we're worried about right now.)

A large part of our testing involves continuity tests between various ports, based on a configuration file and selected by the part number.  We've found (the hard way - by a failure at the customer's plant) that if we have a connection between port 3 line 4 and port 6 line 3, it does not behave in a consistent manner.  That is, if we set Port 3 Line 4 LOW then read Port 6 Line 3, we nearly always read a LOW on Port 6 Line 3, even if the connection is not actually connected.  However, if we do it the other way around (set P6L3 and read P43L4), a missed connection is detected.

At startup and before each test run, the initialisation code below (also attached) is run:

I wouldn't be surprised if I should be running the DAQmx Start Task function between the Create Channel and Clear Task functions to initialise it properly.  In fact, I'll add that in today just to make sure.  Would it be safer if I also did an explicit read, even discarding the results?

What we've also found is that inserting a VI to read all the DIO inputs in turn and check the results (using the Read DIO Input VI attached) also made the port behave correctly.

Does anybody have any other thoughts on this matter?

Regards,

Geoff

[GeoffF]

Here's the image that didn't get attached

[Matthew_Kelton]

What's your test circuit look like?  How does one DIO channel make it to the other?  DO you have pull-up or pull-down resistors and what value are you using?

[GeoffF]

Hi Matthew,

There are no pull-ups or pull-downs.  The DIO port pins go direct to an SCB-100 connector block, then are wired directly to connectors to plug into the DUT.  In this case, the DUT consists of lengths of wire, some with splices to multiple connectors, most direct from point-to-point.

It's probably about as simple as you can get, EXCEPT that the particular suspect circuit also has a connection to port 7, line 5.

We can simulate the whole system with clip-leads connected between the SCB-100 pins here.

Just to add complication, the system was rolled out to production before we had a chance to run even a small amount of testing.  We can't interrupt the production testing (due to delivery pressure) and we don't have access to full test facilities at the lab - in fact, we're running short on hardware due to shipping it all out to production.

I'm wondering if a delay between the write and the input start would be appropriate, too.

Regards,

Geoff

[johnsold]

According to the datasheet the PCI-DIO-96 has 100 kohm pullup resistors. 

What happens if your cable has shorts which result in two outputs being tied together? Does this damage the board? A note on page A-2 of the manual suggests that the DIO lines connect directly to the 82C55 IC and have typical current drive of 2.5 mA. It also mentions that excess current can damage the device.  I would consider putting 2.2 kohm resistors in series with all outputs to protect the DAQ devices.

Have you verified that the individual inputs and outputs all work when connected to appropriate loads and measurement equipment (not just a cable)? 

Lynn

[GeoffF]

Hi Lynn,

In actual fact, the cable has three connections on that particular line - one to port 7 line 5, one to port 6 liine 3 and one to port 3 line 4.  There are NO other energy sources.

In this case, we're setting port 3 line 4 low, which is not a problem.

Stepping through the code, we hit our problem in the Read DIO Input VI (attached to the original post).  As soon as we execute the "Start Task" call for port 6 line 3, with the connection to port 7 line 5, but WITHOUT the connection to port 3 line 4, the bits drop to a 0 level - and stay there until we explicitly set them as output HIGH after executing the test.

Regards,

Geoff

[johnsold]

Can you post your main VI? The VIs you posted look like subVIs and it is hard to follow from your descriptions just what is happening.  The repeated Create Channel, Start, Read or Write, Clear seems a bit strange and inefficient.

Lynn

[GeoffF]

 Hi Lynn,

The actual testing is done a fair way down the chain.  There's a lot of configuration and user interface stuff in there and a lot of other testing going on.  On top of that, I'm not entirely sure how much of the code I should be sharing.  There's not much commercially-identifiable stuff in there and certainly no novel algorithms, but I still need to be sure.

The basic flow is this:

1. Read the config file at startup
2. Initialise the hardware (including the DIOs).
3. Wait for the user to enter part number and serial number.
4. Run the test:
1. Try to find the configuration for the part number (fail if not found)
2. Initialise the DIOs again (to ensure they're in a consistent state)
3. Run 4-wire resistance checks on up to 8 circuits connected to DAQ pins (as configured for the part number). This part is not a problem.
4. For each configured DIO pair for that part number, run a continuity check:
1. Set the "base channel" to output 0.
2. Read the "measurement channel" to confirm it's also 0.
3. Reset the "base channel" to output 1 and then as an input.

There are probably (OK, certainly) less inefficient ways to do all the above (and I've been working on some of them), but I'm not massively worried about the efficiency at this point.  Our concern is the odd behaviour of the port dropping low when it's set as an input with another (input) port tied to it.

At the VI level, the Main VI calls the Read Config VI, which (among other things) calls the Read DIO Config VI to do step 1.

It then calls a bunch of hardware initialisation VIs, including the Initialise DIOs VI to do step 2.

Once the user has entered the part number and serial number (step 3), the main VI then calls the Run Test VI to do step 4.

Inside the Run Test VI, separate VIs handle each of the sub-tasks.  For instance, the continuity check (step 4.4) is run by the Test Continuity VI.

I'm not sure which of the many, many, many VIs in the project would actually be of value here.

On looking at the datasheeets in more detail, we see that it's either the whole port as input or output.  We have confirmed that there are (purely fortuitously) no circuits we're testing that have two ends on the same port.

Regards,

Geoff

[GeoffF · Accepted solution]

Hi Again,

Here is the minimum modification to the initialisation code we've found that makes the test work reliably:

All we had to do was start the task and, like magic, everything came good.  Now to put that into the Production version.  The worry is that it mostly worked without the mod.

Regards,

Geoff