Problems With PC Control/Implementation Of USB-6002 DAQ

[Rob_Fenn]

Good morning all,

Can any of you help me understand what is going wrong here? Has anyone else come across such a problem as I am experiencing?

Background:

In my company we've a VI we use somewhat universally in our test rigs to control (via serial comms) a relay card. The relay card requires serial communication to select which array of relays are to be set/unset, and this VI takes in an unsigned 32-bit value and outputs it to the relay card using three NI DAQ Digital outputs as 'RCLK', 'SCLK' and 'Data' lines. This relay card control VI has been implemented on various PCs with a selection of different NI DAQ models in the past, and has worked reliably.

Current Situation:

The purchase of two new USB-6002 DAQs has brought about a very odd problem; the use of this VI via these DAQs is causing spurious and random operation of the relay card on all of our PCs, except for one of them. We have used this model of NI DAQ (USB-6002) in the past and currently have three running with this VI perfectly fine. It is only these two new recently received NI DAQs that we are having these issues of controlling the relay card with on all of our PCs (running either run-time engine or full LabVIEW 2016) - all except one of the LabVIEW 2016 PCs, where the operation is fine. To ensure it wasn't any odd hardware dependency, when we first encounter this problem with the first new USB-6002, we instinctively created a new fresh project and VI, implementing a copy of the relay card control VI fresh from a known working project on another one of our PCs with LabVIEW, but it also operated incorrectly as originally seen with the first new NI DAQ. 

Anyone know any reason why we're getting spurious control via these two new NI DAQs on all but one of our PCs, while all existing NI DAQs still provide good control on all PCs? 

Cheers all,

Rob F

[Bob_Schor]

OK, you are using the USB-6002 to create an unspecified Digital signal (baud rate?  Protocol?  Data Bits?) using unspecified wiring (which terminals?  how wired?  intervening circuitry?  isolation/grounding considerations?) using LabVIEW (I presume 2016, but don't understand what you mean by "Run-Time Engine", unless you mean you have created an Executable).

Do you think an "un-educated guess" would be helpful to you?  Can you think of anything you can do to make it either an "educated guess" or a "here is where you might make some changes"?

Bob Schor

[Rob_Fenn]

Thanks Bob for your swift reply;

I wanted to pose my question in a manner to steer people from instantly jumping on a "lets debug the VI" angle and thus and wanting to know what the VI is doing internally (baud rate, line pinouts, etc...). I only included scant info about what the VI does purely as inconsequential background to the problem I am seeing, as we know the VI itself is fine and has been running in various test applications, with various NI DAQ hardware (including three older USB-6002 units bought a year ago), for ~4 years now. It appears to be the operation of the DAQ hardware in relation to the PC, rather than an issue with the VI itself.

In answer to your questions, though;

• Terminals: Dport0/line0 is 'RCLK', Dport0/line1 is 'SCLK', Dport0/line2 is 'DATA'.
• Wiring: From DAQ DI/O terminals --> via simple 2N7000 level shift circuity (3.3V to 5.0V) --> via 40106 Schmidts --> 74HC595 shift registers to select the required relay combinations (via ULN2003). All 0Vs tied common.
• Baud rate: We're using the natural loop iteration as the "clock", and this has been fine with all previous hardware. We've tried modifying the loop with a 50ms wait (so less than 20Mhz) to ensure its within the 25Mhz max serial clock rate of the 74HC595 shift registers @ 5V (even though it's previously been working fine with all other hardware without the wait implemented, except these two new USB-6002), but to no avail.
• LabVIEW Versions: 2016 Full for build on a few PCs, a mixture of 2018/2019 Runtime for running the executable versions of the VIs on all other PCs.

The problem we're seeing is seemingly more to do with the communication between LabVIEW (build and runtime engine) on the PCs and these two new items of DAQ hardware, where-as all existing DAQ hardware (even those of the same model) work with our VIs fine. No error messages are present, DAQs are correctly named via NI-MAX with each PC they're plugged into, and the VI runs through as if all is fine. Has anyone encountered such spurious operation of new DAQ hardware, where existing hardware operates fine? Has anyone encountered spurious operation of a particular DAQ running a VI on one PC (a PC which normally runs VIs with other DAQ hardware fine), yet on another PC that particular DAQ runs with the VI fine?

[mcduff]

---

@Rob_Fenn wrote:

Anyone know any reason why we're getting spurious control via these two new NI DAQs on all but one of our PCs, while all existing NI DAQs still provide good control on all PCs? 

---

Just guessing: Check the USB cables, USB ports, make sure they are not on power save. Look at the device manager, are the USB ports you are using on the new computer shared by other devices? Most of the issues I have had with USB DAQ devices, is the USB port itself. Have a good cable and the DAQ isolated on its own port.

good luck.

mcduff

[Bob_Schor]

Well, a colleague of mine is very unhappy with the (relatively flimsy) cables of the USB-6002 compared with the USB-6009.  McDuff is probably on to something ("Check the cables").

Bob Schor

[GerdW]

Hi Rob,

with a 50ms wait you are million times away from 20MHz...

[MichaelS78]

You need to get a scope or logic analyser on the fiditsl control lines and look atthe timing and voltage levels with old and new cards. When I did this with a 6009 10 years ago, it worked very well, the whole loop with no timing gave me a clock rate of 500hz, that is 1ms per edge.  These cards are not designed for timing signals like this sonits possible you had it working at the edge of specification or beyond the specification. A scope is the only thing that will help you here I think.  Ley us know if you can scope the lines and post some comparison images