Using Tristate to clear Couter Counter Output Routing causes line to be pulled low momentarily

[erk1313]

Specs: USB-6341, Labview 2011

Goal: Create a timed counter output pulse (Ctr0)  to one of 5 PFI ports (PFI0-PFI4).  The signal is active low.   The PFIO port turns on a SSR relay for ~40ms.  The relay has a 3.3kOhm pullup resistor on the DAQ line.

Method: Counter ouput pulse (ctr0) is routed to one of five PFI ports ...., pulse is sent , then the route is cleared using a tristate command.  See Post on clearing routes, otherwise the route remains effective when the counter output pulse is run a second time with a different port, causing both ports to go low.

Problem: The startup state and pulse idle state is set to high (since the relays are active low).  However, after the pulse is sent, when I send the tristate command to disconnect the routing, the line goes low momentarily before the pullup resistor can kick in, causing a glitch in the relay.

DAQ signal from PFI0 is blue (top).  Notice the small glitch after the pulse when tristate is called.

120VAC Relay output is yellow (bottom) .

[erk1313]

Help! Any thoughts!!!!

[ianidas300]

I have a few questions regarding your setup and implementation. Can I get a wiring schematic, model number of the solid state relay, and a a waveform of the signal without the tri-state command? Also, a potential workaround for this issue would be to set the idle state to low and active high. Then use an external inverter going into the active low relay. If the tendency for the tri state command is to pull the line low, having the idle state as low will not result in a glitch.

[erk1313]

That is a really good suggestion to use an inverter and make the DAQ active high. 

However, I am still confused why the tristate would bring the line low.  Here is the schematic.  Note for others: these relay boards integrate nicely with the OEM DAQ, but you have to cut one of the ribbon cable GND connections else it shorts a 5V pin). 

[ianidas300]

Does connecting to a digital IO rather than the PFIO change the output?

[erk1313]

I don't believe a counter can be routed to a digital I/O, but please correct me if I am wrong.  I am using counters because I need an accurately timed 40ms pulse.

[erk1313]

Here are the results of two more configurations that NI asked me to run:

1. No Tristate: Same as the VI in the first post, but without using the tristate to disconnect the routing.  This gave the pulse I need, but doesn't really helpI since I still need to disconnect the routing to connect the counter to the next PFI1 line.

2. No pull up resisitor: This is the first VI, but with the DAQ by itself (no pullup resistor).  You can see how the tristate pulls the line low. 

[erk1313]

Another Configuration that NI had me try.  This VI is the typical write on, write off, but does not use the counter or PFI ports so the timing isn't very accurate.  I generally received a pulse that was 2ms too long (+-1ms).

I need a 40ms pulse, but I shortened the VI to 5ms to zoom in on the o-scope. Pulse should have gone high at the center of the scope (5ms mark), but instead it varied from 6.5-7.5ms in width.  Not bad, but for a +$1000 DAQ, I am hoping for better.  (Two captured signals shown as overlays)

[ianidas300]

The DAQ isn't the problem here. It is a software timed output which doesn't yield the same results as hardware timed output.

[erk1313]

lanidas300: Yes, without the counter, the software timed output is polled and can lead to the delays shown.  That is why I am using a counter.

There does seem to be a problem with the DAQ pulling the line low in tristate mode.  The tristate has a 20k-50kOhm pulldown, while I am using a 3.3kOhm pullup.  If the tristate is truly floating than it should never be pulled down.

For reference, the relays are Crydom OAC5R, mounted to a GrayHill 70RCK16-HL relay backplane.