Keithley 6487 Serial Communication Errors

[bcmasters81]

Hello,

I am trying to develop a VI for connecting to a Keithley 6487 Picoammeter/Voltage Supply, sourcing a voltage, and measuring a current.  Here is the info on my system:

Dell Intel Dual Core 3.2 GHz

Labview 8.6

Keithley 6487 (the one with the voltage source built in)

USB-to-Serial adapter for communications 

All commands are done via SCPI, and I use the VISA components for communication.

The main problem is that after reading the data off of the 6487, I get the following error:

 -1073807254 (VISA: (Hex 0xBFFF006A) A parity error occurred during transfer.)

In terms of communication, I am using:

57600 baud

Xon/Xoff flow control

1 stop bit

ODD parity

8 bit

LF (Line Feed) and the end of a command

I have included the VI, Untitled 2.vi.

Other than that, I would like to make some other changes.

First, I have put in a 3 second delay between the "READ?" command, and actually reading the data.  I'd like to have the picoammeter signal LabView when it is ready, so the VI waits the minimum amount of time before retrieval.

Second, I would like to use the commands that are built-in to the 6487 for doing sweeps.  One of the things that prevents the sweep commands from being executed properly is the same error as above, but it also seems to have trouble taking a data point for each voltage, perhaps some sort of triggering issue.  I'd rather NOT put this in a "while" loop, because the 6487 can do the sweep much faster and store all of the data in the buffer, rather than having LabView do each measurement one by one, read the data, flush and clear the buffer, and repeat.  I've included this code as well, named Untitled 3.vi.

Any help would be most appreciated, and thanks in advance!

[Albert.Geven]

Hi

Compliments for your work.

I see that you did learn LabVIEW from scratch, and before I start about the solution for your problem first some words about style.

And because I'm noted as a desequencer by my coworkers, I first need to say that all sequence frames can be removed from your vi.

The correct used errorin/errorout connection assures that the visa writes and reads are executed in the order you connected them.

Second, you can make your program much more readable, but most important more easy to write by using subvi's.

the most repeated piece is the format into string followed by the visa write. If you  make this a subvi your program will be more compact.

Although that improves the readability you still have to know and feed correct strings for each command and that is  errorprone.

I'm not saying that you made an error, just that this is a way of programming in which it is easy to make errors.

So instead of putting a string and a visa write you should look into the wayto abstract this layer.

Look at the example for the agilent driver in the instr.lib directory and especially look at the lowest level vi's that use the visa write and read.

Ok what I meant about respect for your work is true, I started 35 years ago with programming and understand this way but don't use it anymore.

Now a probable solution. A parity error means that the machine uses another parity than you. So the parity shown in  untitled 2 isODD

and LabVIEW checks for that. Maybe it should be NONE, that is mostly the case.

Or your cable is way too long (more than 20 meter) or your usb to serial adapter is making a mistake.

But I would try parity none first. (It should be the same on the keithley side)

[bcmasters81]

Hello,

First, thank you so much for the quick and comprehensive reply.  I really appreciate your compliments, as I am just a fledgling novice when it comes to LabView.  I have next to 0 programming experience (high school Visual Basic and C++, Mathematica, and the odd program on my old TI-85). I've noticed that the forums have become a place of criticism first, education later; but I am happy to find an exception in you.  Thank you.

Let me respond to each of your recommendations in turn:

I first need to say that all sequence frames can be removed from your vi.

The correct used errorin/errorout connection assures that the visa writes and reads are executed in the order you connected them.

This is excellent news, I will definitely remove the flat sequence structure.  I have to admit, this code is not entirely mine.  I found code from a user facing similar problem, although they were not able to have any successful communication at all.  I built mine based on parts of theirs, and the sequence structure was part of it.  In the original code, the errorin/errorout inputs were all fed from a single errorin in parallel, which is perhaps why it didn't work in the first place.

Second, you can make your program much more readable, but most important more easy to write by using subvi's.

the most repeated piece is the format into string followed by the visa write. If you  make this a subvi your program will be more compact.

Although that improves the readability you still have to know and feed correct strings for each command and that is  errorprone.

I'm not saying that you made an error, just that this is a way of programming in which it is easy to make errors.

So instead of putting a string and a visa write you should look into the wayto abstract this layer.

Look at the example for the agilent driver in the instr.lib directory and especially look at the lowest level vi's that use the visa write and read.

I have had some bad experiences with SubVI's, not so much with writing or using them, however, if their location is moved on the computer, when the main VI is started, LabView looks for it, and will often pick another (similar, but incorrect) file before I have a chance to choose the correct one.  Again, I like SubVI's, I just don't like how LabView handles finding them when they are moved.

Eventually, this code will become a SubVI unto itself.  My philosophy on SubVI's has been to make one for each diagnostic of my total system.  I have also tried writing SubVI's for heavily repeated code, but it is difficult to know how large the code needs to be in order for it to merit its own SubVI.  Would 3 small elements (like a numeric constant, a ">", and a "+") be enough if used multiple times in the code? 6 elements? 9?  This is an issue for another forum, but I welcome your advice on the most efficient method.

Now a probable solution. A parity error means that the machine uses another parity than you. So the parity shown in  untitled 2 isODD

and LabVIEW checks for that. Maybe it should be NONE, that is mostly the case.

Or your cable is way too long (more than 20 meter) or your usb to serial adapter is making a mistake.

But I would try parity none first. (It should be the same on the keithley side)

OK, when you say "the machine", are you referring to the picoammeter, or the computer running LabView?  The picoammeter does indeed have its parity set to ODD, as was the code, as you noted.  However, the COM port itself has defaults when the VI is not running, and that may have a parity that is not ODD.

I am happy to try out NONE parity on the VI and the picoammeter.  The reason I set it to ODD, was because after speaking with some people on serial communication, they said NONE parity is a last resort, with ODD and EVEN preferred.  Is this incorrect?  Please let me know

The cable length (serial cable) is only a few feet, the USB cable is longer, but has a powered hub to strengthen the signal.  I had not considered the possibility of the serial adapter making a mistake.  I assume I can test for this by connecting the picoammeter directly to the computer via serial port, and running.

Also, why does the parity error only show up in the last few steps, rather than early on if the parity is wrong?

Thanks again, I look forward to your response!

[Albert.Geven]

Hi good student.

I like your style.

And I agree LabVIEW need vi names, and can find the wrong for the orther.

But the project feature helps you.

Create an new project. Give it a nice name and put your important vi in there. And from LV8.5 on it will ask you to choose between the former position and the found one.

About the parity error you are right. It is better to have a parity check and it is strange but not impossible that it happens on the last communication, but was it the last coomunication.

When an error is occuring no further VISA IO is executed only the error is passed.

Sleep well, It's Sunday over here.

[bcmasters81]

Hello,

I removed the case structure today and tested the VI, and it worked fine.  So that eliminates that problem.

I tried setting the parity to NONE on the LabView VI and the picoammeter itself, and this caused a problem:

-First the code would execute once properly, and when it returned the data (voltage and current), it returned them without the annoying spaces in between some of the digits.

-Second, it returned a different error, ending in 339, but it was a "green" error, not a "red error", so it executed the last statement after reading the data.

-Finally, when I tried to run it a second time, the VI would hang and not do anything.  I tried stopping the VI, which didn't work.  I tried quitting LabView, which also didn't work.  I had to do Crtl-Alt-Delete and go into Task Manager to shut it down.  Once I had told it to "End Program", the VI would close, but a small window that said "Resetting VI: ______" would come up, and after a few minutes, I'd get the blue screen of death.  So NONE parity will nto work.  I tried EVEN parity, which gives me the same error as ODD parity.  I also checked the cable length.  I'll try using a serial cable direct into the computer without the USB-serial converter, but other than that I'm out of ideas.

Any other things I could try?

Thanks in advance!

[Albert.Geven]

Hi

 So it definitely is not the parity that bothers you but that after the first run, the system seems to hang(and I bet it really hangs).

Probably the system returns to a mode in which it either needs some extra data out or is waiting for something else to happen.

The green "error" is a warning and it is always nice to copy the warning (you can doubleclick on the message and copy it)

maybe it says you are reading exactly the number of bytes you wanted to read, and that annoying message is just an idiot message.

maybe you can add a statement that checks the number of databytes left in the serial buffer. (visa bytes at serial port)

But I'll have a look at your code again.

[bcmasters81]

As a matter of fact, I re-considered what you said about the USB-serial adapter, and messed with the parity of the picoammeter.  I set the picoammeter to EVEN parity, and the VI to ODD, and it worked!!!  I seems that the USB-serial adapter flips the parity, that probably means both the VI and picoammeter are correct, but I just have an issue with the adapter.

Now, all I need to do is get the VI to send sweeping commands, and I'm all done!!!

Thanks!

[Albert.Geven]

congratulations

and happy wiring

[mhapu1996]

Hi, I am new to Lab View programming. I also have one 6487 picoammeter. can you kindly share the final VI with me.

[bcmasters81]

I haven't used these in years and they were written with LabView 8.6(?) so you will likely have to have them converted to work with newer versions.

Best of luck to you!