Keithley 2700 continuous read locking up

[CS_TAT]

New to LabVIEW - I'm running through all of the Core 1 level stuff and am up to the DAQ section.

I'm trying to read up to 39 thermocouples continuously from a Keithley 2700 DAQ/multimeter with a 7702 multiplexer and am banging my head against a wall trying to make it work.

To start with the most simple case; completely unmolested Keithley 27XX Continuous Multi Read example.  I've input the correct VISA resource name.  I'm connecting via RS232 to USB cable.  Serial Configuration matches the instrument (Baud Rate = 9600, Flow Control = None or XON/XOFF - tried both, and Termination Char = CR).  I hit run and the instrument clicks on and begins cycling through the 10 channels set in the example.  After a few iterations (appears to be a random number as I've inserted an indicator for the counter messing with this...I see as few as 2 with the unmolested example and as many as 3 if highlight execution is enabled) the program will lock up.  The Keithley is still clicking away, but the LabVIEW program cannot be stopped and will not proceed past however many iterations of the loop it decided to run.

I've tried many versions of this type of measurement with the other options: Multi-Point (Buffer Subset) - the default for the program, Multi-Point (Entire Buffer), and Multi-Point (Direct)...all lock up.

I've run a different DAQ - a PDAQ 56 (USB only connection) using the appropriate drivers with little issue.  But the Keithley just will not run continuously. I can't find anyone with a similar issue in hours of searching - so I'm assuming I've missed something simple - especially given the as-supplied VI example isn't working.  What am I missing?

[CoastalMaineBird]

I've got a system with 10+ Keithley 2701s, sampling 10+ channels each at 10 Hz, and they all go without a hitch.

But I'm using direct TCP connections. No VISA, no USB<->Serial boxes,

I would suspect something in the VISA / USB linkage.

Do you have another way to connect?

Can you monitor the data received, via an indicator or a file-write?  Perhaps that would yield a clue.

[CS_TAT]

Short answer, no, I don't have another way to connect the DAQ.  The DAQ has the option of a GPIB interface, but I do not have an adapter/controller to get it hooked into the computer.  

I've run a loopback test on the RS232 to USB cable that turned out fine.  I'm not sure how to go about testing it in more detail.

I'm fairly certain that the DAQ is operating fine given it continues to scan the channels even when LabVIEW locks up.

I have another VI for a power supply that is controlled via a serial connection (its USB to USB, but is registering in MAX as a serial instrument).  The program runs perfectly (requiring writing to and reading from the instrument inside a while-loop) but only if highlight execution is enabled.  If I disable highlight execution, I get erratic readings from the instrument, as if it didn't have time to complete the data transfer.  Could be related, could be my program.

All of this seems to come back to a serial communication issue - but I don't know where to start trouble-shooting.  If we eliminate the program (NI approved), the instrument (appears to be working properly), and assume the cable is fine given the loopback test and the second program's read/write issues with a USB-USB cable, what else is there?

[CS_TAT]

Sorry, forgot to reply to the last part of your post:

I've managed with some other versions of the program to use a waveform chart - the data is reading correctly up to the point it locks up.  If I stop data aquisition before the program locks up, I also get the correct readings from the indicators.

[Dennis_Knutson]

I don't believe the loopback test is at all valuable.

Who makes your USB-RS232 chipset? FTDI, Prolific? What version of NI-VISA? What os? What version of LabVIEW? What bitness?

P.S. DAQ has a special meaning here. DAQ would refer to the data acquisition devices from NI. Yours is an instrument control issue.

[CS_TAT]

Who makes your USB-RS232 chipset?  Chipset?  As far as I know, its just a cable - Insignia.  

What version of NI-VISA? 14.0.1

What os? Windows 7 64 bit

What version of LabVIEW? 14.0.1 32 bit

What bitness? I'm assuming you are talking about 64 vs 32 bit - see above.

[Dennis_Knutson]

It's not just a cable. There is an ic inside that does the conversion. Check in Windows Device Manager for the name of the driver. I've always had good luck with FTDI. Less so with Prolific and a lot are counterfeit.

[CS_TAT]

Driver is Prolific 3.4.67.325

Cable is easy enough to try - ordered one with a TDMI chipset and can try it out tomorrow.

Thank you,

[billko]

If it is this, it's Prolific.  I looked at the user manual and it's installing prolific drivers.  (That's the only way I figured it out.  They don't mention the chipset, even in the spcifications.)

edit - oops, i'm late, aren't i?

[Dennis_Knutson]

Sorry, I never heard of TDMI.