PXIe-6556 Static Generation - can't get all DIO channels to logical 1

[BoilerBob]

I'm running NI-HSDIO 20.0 on Windows 10 Enterprise.

I'm trying to use Static Generation with a PXIe-6556 card.  When using WriteStaticU32() with writeData = 0xFFFFFF and channelMask = 0xFFFFFF, I'd expect all 24 DIO channels (0 - 23) to go to a logical 1 (3.3 V in my case).  Instead, some channels are staying at a logical 0 (0.0 V).

• I'm using a CB/SCB-2162 breakout board to check the signal levels.

Specifically, DIO 1, DIO 2, DIO 7, DIO 8, DIO 13, DIO 14, and DIO 20 stay at logical 0.

With writeData = 0x000000 and channelMask = 0xFFFFFF, I'm able to put all 24 channels to logical 0.

What am I doing wrong?  I've attached my C# code.  As noted in the code, it's adapted from StaticGeneration.c example in NI-HSDIO\Examples.

[santo_13]

How does it respond to the Soft front panel?

After StaticWrite, do a StaticRead on the same channels to know if the pin drive circuit is driving it right.

[BoilerBob]

Unfortunately, the soft front panel (Test Panel) isn't available in NI-MAX 20.  (Yeah, that was my reaction as well when I discovered this.)

Doing a Static Read is a good suggestion.  I'll give it a try next week.  (I'm taking Friday and Monday off.)

[BoilerBob]

I've modified my code to do a static read as well as a static write.  (See the attached Program.cs file.)

When I do a static write of 0xFFFFFF and then a static read, I get decimal 15703673, or hex 0xEF9E79, or binary 111011111001111001111001.

This matches what I got when I tried measuring the voltages on the CB/SCB-2162 breakout board's DIO channels, with DIO23 as the MSB and DIO0 as the LSB.

Why am I not getting 0xFFFFFF as my static read when I do 0xFFFFFF as a static write?

According to NI-MAX, my 6556 card is passing its self-test.

[santo_13]

I could think of this in two ways - either a bug in the driver or damaged HW

FYI - Self-Test does not check for the HW functionality completely, it just checks if the driver can successfully communicate with the HW.

If possible, try older versions of HSDIO driver with a soft front panel. Try to use example programs on LV to see if the same behaviour exists, if you have tried all means then the last resort is to send back HW to NI for repair.

[BoilerBob]

First, thanks for the tip about the self-test.  I should have realized that the speed at which it ran meant it wasn't a complete test.

Re: Trying an older version of HSDIO.

Unfortunately, all the systems which might have older version of HSDIO or which might have a soft front panel are production systems, and are in more-or-less continuous use.  (I'm working with a development system.)

I can re-seating the 6556 in its current slot in the PXIe box, or even try moving it to a different slot.  Maybe I'll get lucky?  I can also see if we happen to have any other 6556 cards lying around.  Not too likely but again, maybe I'll get lucky.

Thanks for your help and suggestions!

[crossrulz · Accepted solution]

I would start by disconnecting the cable from the PXIe-6556 and do your test again.  This is a way of trying to isolate a possible short or something like it in the connector block and/or cable.

[BoilerBob]

Thanks!  Yeah, that idea occurred to me at home last night.  I need to verify that there's no short in the cable.  Or in the breakout board, for that matter.

It's good to get confirmation that it's not a totally crazy idea; that someone else thinks I should check it.

[BoilerBob]

OK, I just got into the test lab and tried things out.

With the VHDCI cable disconnected from the 6556 card, a write pattern of 0xFFFFFF (all logical 1's on the 24 DIO channels) gives a read back of 0xFFFFFF, as expected.

However, with the VHDCI cable connected to the 6556 card but disconnected from the CB/SCB-2162 breakout board, the same 0xFFFFFF write pattern gives a read back of 0xEF9E79 (binary 111011111001111001111001).  That's the same result I got with the board connected - see a few posts up.

Obscenity, profanity, profanity, bleepety-bleep!!!

You cannot IMAGINE how much time I've wasted on this.

My thanks to crossrulz, even though I came up with the same idea independently.  I've given you a kudo.

[crossrulz]

---

@BoilerBob wrote:

You cannot IMAGINE how much time I've wasted on this.

---

We've all had those moments, many times.  A couple of years ago, I wasted probably a week trying to figure out why a unit was resetting on me only to discover I didn't set the power supply's current limit high enough (caused a brown-out).  Learn from your mistakes and move on.