Hex 0xBFFF003A error with Keithley 2400 sourcemeter

[arimoo]

Hello guys, 

I have a problem that I have been scratching my head with for a week. I have a Keithley 2400 sourcemeter, I want to control it with my computer using Labview. I have done the following steps: 

1- I used the Labview Instrument drivers but unfortunately executing any labview driver results in this error: 

Spoiler

  VISA:  (Hex 0xBFFF000E) The given session or object reference is invalid.

2- I could communicate with the device using the simple serial communication example. but the device just responds to the write commands. I can set some parameters on the device but I can't read anything. 

3- Using NI max I still can send commands to the device, but trying to read the status byte or  sending any read commands results in error: 

Spoiler

VISA:  (Hex 0xBFFF003A) Unable to start operation because setup is invalid (due to attributes being set to an inconsistent state).

I am using labview 2017, and serial to usb converter (ch340). I don't know where this frustrating issue comes from and I haven't been able to fix it. 

[cstorey]

How are you physically connected to the instrument?  RS232 or GPIB?  If RS232 make sure its a straight thru and not a NULL MODEM cable.   You need to go to the 2400 front panel and press the MENU button.  Then select COMMUNICATIONS and make sure its set to GPIB or RS232.

The LabVIEW drivers sent SCPI commands to the instrument, regardless of physical connection, so once its connected properly you specify either the GPIB address, or RS232 settings.

When you turn the 2400 on, take note the Revision number, if it says SCPI and what the GPIB ADRS= is.  Revision should be C32, that's the latest firmware I'm aware off and solved lots of little problems.  If you are using GPIB then you need to put that address in the code.  

From there you should be up and running.  Post code or a screen shot of your code if it doesn't work.

[cstorey · Accepted solution]

I just saw that serial to USB converter part, that might be your issue.  Follow all the first advice, then try another Serial to USB.  Not all of the cheap ones work as expected!

[arimoo]

Thank you very much for your reply. I can send SCPI commands to the device. the device responds to the write commands and recognizes syntax errors, but I can't read from the device. Reading results in errors. About the serial port type, do the usb to rs232 cables have different types too?(null modem or straight through)

[cstorey]

Have you tried running any of the examples that come with the driver?  Those should work without needing any modifications. 

There is no reason a write command would work and read not, unless you have setup the measurement/trigger incorrectly.  Post your code if you want help with that.  

Yes, there are RS232-USB null modem varieties.

[arimoo]

Yes I started with the default examples and they didn't work so I started writing my own vi. I will send the codes and screen shots tomorrow when I go to the lab. 

[Minions]

Try this Simple Communication vi.  You may need to setup the front end for Serial Communication by replacing the VISA resource name.

[Viel]

we tried using the examples that came with the drivers but they always gave an error in the visa read. 

we made our vi attached below and were able to control the Vsrc and Isrc without any problems. however when we tried using the keithley to read a signal and get the data for that signal on the computer it fails and doesnt give anything. im using the :sens: commands to trigger measurement operation and trying to read from visa read. i hope you will be able to help.

[arimoo]

Thank you everyone for your help and insights. The problem was with the cables. I managed to get some other cables and they worked like a charm. 

[cstorey]

Ok, you have a few problems in your code.  

1) The VISA serial is set to automatically add a termination character "\n" and then you are adding another to each of your commands.  I would take the "\n" out of your strings.

2) In some of your strings you are using "\" codes display and some are normal display.  I'd stick to one format or the other and also use the display style to tell them apart.   I say this because where you are setting the source you are using normal display but you have \s and \n in there, which means you send the instrument \\s and \\n which it won't like.  This will give an error.

3)  You send *RST, then a pile of other commands right away.  A reset takes 1-2s, and in that time those other commands might be ignored.  I'd put a delay in after the reset, maybe read the *IDN? to know the instrument is ready, then send the pile of commands.

4) You are using bytes at port to do a reading over serial bus.  NOT a good idea.  Just use a reasonable large size, say 1024.  It will read as many bytes as the instrument returns up to 1024 bytes, but since the termination char is being used it stops as soon as that is reached anyway.  In this case you are going to get about 14-20... so 10-20 is plenty of extra space.  

5) You are sending 8 decimal places with your %02.8g formatting.  The instrument will probably ignore most of those, but it might cause an error...you'd have to RTFM.  I would use 3 at most to be safe.  

Try to fix all those issues in your code and see how you make out.  If I were you I would start over with the K24xx driver VIs, say the "Sweep and Acquire Measurement.vi" and try running those again.  Then build from those toward your program goal.