NI-VXI 8360T does not maintain timing of SCPI commands

[Dan from EADS]

I am using a NI-VXI 8360T with a VXI carrier that controls relays.

The VXI carrier is a message-based device that accepts SCPI commands and then executes 16-bit poke & peek operations on the board inside the carrier.

The (latching) relays requires a minimum 5 second pulse on either the set line or reset line to operate properly.

The driver code looks something akin to:

      Send the SCPI command to POKE the register that asserts the SET (or RESET) line of the relay

      sleep( (DWORD) 8 );   // windows sleep function / 8 milliseconds

      Send the SCPI command to POKE the register that deasserts the SET (or RESET) line of the relay

This has worked without error on the traditional MXI-2 interface to the card.

However, with the 8360T, this intermitently fails to actuate the relay.  Looking at the RESET pulse line of the relay, it normally is a solid 8 msec pulse, with intermittently short pulse (< 1 msec), in which case the relay does not actuate.

I have even tried modifying the driver code to do the following:

      Send the SCPI command to POKE the register that asserts the SET (or RESET) line of the relay

      Send a "SYST:ERR?" query to the carrier

      Read the reply from the carrier (to synchronize the PC with the carrier)

      sleep( (DWORD) 8 );   // windows sleep function / 8 milliseconds

      Send the SCPI command to POKE the register that deasserts the SET (or RESET) line of the relay

      Send a "SYST:ERR?" query to the carrier

      Read the reply from the carrier (to synchronize the PC with the carrier)

This still does not work on the new MXI.

Also, one more odd item to note is that if NI-spy is turned ON, and then OFF (so it is not capturing traffic), this seems to rectify the problem.

This indicates that the behavior VISA/VXI software in conjunction with the 8360T  appears to be altered by enabling NI-spy even without capturing the data.

[Mr.F]

Hi Dan,

I’ve been working with Carl on this issue; let’s clarify a couple bits. The SET (RESET) line you refer to, is this internal to the DMM you are controlling or are you referring to a VXI P1 or P2 pin by a non-default name? Can you characterize what you mean in this line: “it normally is a solid 8 msec pulse, with intermittently short pulse (< 1 msec), in which case the relay does not actuate” The intermittent short pulses are momentary lows in an otherwise high 8 ms pulse? Can you probe this line with an O scope and observe this behavior? Please post a capture of this behavior if you can. If you adjust the wait to something much large like 100, or 500 ms does the relay actuate? Do you see the same pulses on the SET or RESET lines? How often does this intermittent behavior occur? Every time? Every other? Once a day, week? Working with Carl previously this was limited to one 8360T in particular while others functioned properly. Do you, or Carl, have a second rev B 8360T?

[Dan from EADS]

Matt:

The SET (RESET) are two separate lines on our interface card inside the VXI carrier.

They are controlled with SCPI "POKE" commands to the carrier.  This has nothing to do with the VXI control/data/address lines (beyond using the MXI to send the SCPI commands).

The pulse is low-going.  Normally, the code produces a pulse width of 8 msec (from falling edge to rising edge).  When the intermittent failure occurs, the time from the falling edge drops to something less than 1 msec.

By "intermittent", I have a test program that cycles the DMM (and relay controls on the interface card) as follows:

    Select DCV mode (opens the relay of interest)

    Select ACV mode (closes the relay of interest)

    Select DCV mode (opens the relay of interest)

    Select resistance mode (does not affect the relay of interest, by design it stays open)

    Select DCV mode (does not affect the relay of interest, by design it stays open)

So when the failure is observed, it is always the change from the ACV mode to the DCV mode using this test program.

It happens sometimes as often as every 6th loop, and at other times every 20th loop.

We have performed some more experimentation to avoid the "Sleep()" function altogether.

Based on Microsoft, this is not guaranteed to provide a minimum sleep time when the value is less than 57 msec or so.

Using a "calibrated wait" alternative to the sleep, we seem to be getting more consistent results.  So perhaps the MXI is not the culprit, although it is hard to understand what impact going from old MXI (MXI-2) to new MXI (PCIx MXI) would have on this operation.

Yet we can clearly see an impact when moving to the PCIx MXI from the old MXI...

[Mr.F]

Hi Dan,

The desired 8 ms pulse is active low but intermittently only last 1 ms and thus the relay fails to physically actuate? The registers are being written correctly by the controller, just sooner than you expected? Can you post a link to where you saw the information on the Sleep command from Microsoft? If Microsoft can’t guarantee a minimum sleep time if the value is less than 57 ms can you try a larger sleep time? 

Also, can you elaborate on the “calibrate wait” option that you mention? How “more consistent” is this option.  The MXI 2 and MXI express control options should perform the same behavior (ie register reads, writes, etc.) but the timing of those commands may be different. Most likely faster in the case of MXI express. This slightly slower operation with a MXI-2 connection may have benefited your system in allowing enough time for the relay to actuate before the next poke interpreted by the driver and executed by the device. However, if you have two commands in a row to poke the same resister and the time between is dependent on your code; the hardware difference may exacerbate a race condition