Problems with VISA OPC/SRQ detection

[markus4]

Hi,

first of all I will introduce my self. This is my first post to the LAVA-Forum. My name is Markus and I am from Germany. I work with LabView since the last six month. My task is to build a system for long time current/volltage meassurements for flash memory. My equipment is a Keithley 2612 source meassure unit and LabView 8.5.

I have a question about the SRQ request. In this picture you can see a part of my vi.

I like to open a Service Request than start the meassurement on the Keithley and wait until the meassurement complete. I belive that this code should work, but it won't.

Most of the time the wait for SRQ vi runs into a time out, but the meassurement on the instrument ends in time.

If reset the instrument and also the vi on the first run I get a

warning: 1073676292 at VISA: Discard result in IV_var_1.vi->IV with TSP.vi occurred.

The next run (without instrument reset) I get an error: time out or "error in Keithley 2612.lvlib:Error Query.vi".

I read all the registers of the instrument and the settings for ESE and SRE are ok. A got a signal on ESR (OPC) after the meassurement finished and also on the SRQ bit of the SRR register. So the instrument register had the right setting, but the SRQ-VI didn't identify the set SRQ Bit on the Bus.

Something strange I saw: If I delete the VISA_write_OPC in the vi and start it I also see a signal at the OPC and SRQ line. Why?

But is this the right way to handel this problem?; Do I have a mistace in my vi?; or is anything else wrong?

I hope somebody can please helb me.

Markus

[BrokenArrow]

Guten tag Markus,

I don't have that Keithley driver (vi), so I can't steer you to an exact solution, but I do have a few comments:

• Why do you Enable the Service request then immediately Discard it?
  
• If Keithley supplied a set of VI's to you, then I doubt you even need to enable a VISA service. Check with Keithley for an example.
  

Richard

[Rolf Kalbermatter]

QUOTE (raul70 @ Apr 29 2008, 07:33 AM)

Hi,

first of all I will introduce my self. This is my first post to the LAVA-Forum. My name is Markus and I am from Germany. I work with LabView since the last six month. My task is to build a system for long time current/volltage meassurements for flash memory. My equipment is a Keithley 2612 source meassure unit and LabView 8.5.

I have a question about the SRQ request. In this picture you can see a part of my vi.

http://lavag.org/old_files/monthly_04_2008/post-11104-1209470290.png' target="_blank">

I like to open a Service Request than start the meassurement on the Keithley and wait until the meassurement complete. I belive that this code should work, but it won't.

Most of the time the wait for SRQ vi runs into a time out, but the meassurement on the instrument ends in time.

If reset the instrument and also the vi on the first run I get a

warning: 1073676292 at VISA: Discard result in IV_var_1.vi->IV with TSP.vi occurred.

The next run (without instrument reset) I get an error: time out or "error in Keithley 2612.lvlib:Error Query.vi".

I read all the registers of the instrument and the settings for ESE and SRE are ok. A got a signal on ESR (OPC) after the meassurement finished and also on the SRQ bit of the SRR register. So the instrument register had the right setting, but the SRQ-VI didn't identify the set SRQ Bit on the Bus.

Something strange I saw: If I delete the VISA_write_OPC in the vi and start it I also see a signal at the OPC and SRQ line. Why?

But is this the right way to handel this problem?; Do I have a mistace in my vi?; or is anything else wrong?

I hope somebody can please helb me.

Markus

One other thing I see is the command string to set the ESE and SRE registers. You seem to have them separated with a line feed only. Maybe the Keithley accepts that but it is standard usage to separate several commands in one command string with semicolons from each other. It could just as well be that the Keithley device only sees the ESE command but not the SRE command in this way.

Rolf Kalbermatter

[markus4]

ZITAT(BrokenArrow @ Apr 30 2008, 08:17 PM)

Guten tag Markus,

I don't have that Keithley driver (vi), so I can't steer you to an exact solution, but I do have a few comments:

• Why do you Enable the Service request then immediately Discard it?
  
• If Keithley supplied a set of VI's to you, then I doubt you even need to enable a VISA service. Check with Keithley for an example.
  

Richard

Hello Richard,

I don't use the Keithley vis either, because these drivers are a quick& dirty implementation. So after some learnings with the drivers I made the decision to write these by myself.

The first point is interesting. I found this in the NI examples (enable, then Discard), but this example was for an RS232 connection.

Second Point: Keithley do not provide examples (only the drivers) and my VI for the Keithley has no enable VISA service.

We have some construction work in our lab but on thursday (hope so) I will try your ideas.

An aspects that maybe is a problem:

We use an Keithley KPCI-488LP GPIB card. The Keithley driver for this card is needs a passport for VISA, but the card works (but not 100% tested) with the NI GPIB driver. I am not sure if I use the right passport for visa and if visa uses the right base driver. Keithley has drivers (vi) for gpib but I like to use visa, but I can do some tests with this drivers.

@Rolf:

I belive I tried semicolons to separated the commands and it won't work with the Keithley 2612. In the manual the only describe the a line feed. I have to check this.

The Keithley don't use SCPI commands it has a build in interpreter for LUA.

I will report if I have some news. Thanks for your help,

Markus

[markus4]

Ok, the problem is solved. After many trials (Keithley GPIB card, NI card, formatting the harddisk, installing a new clean system) I found this out:

• The Keithley do not like semicolons or line feeds. With semicolons I get an error, with line feed the instrument only uses the first argument but I didn't get an error. The example I found in the Keithley manual with line feed must be wrong.
  
• The discard Service request discards request that are allready in the queue. This vi must be used.
  
• I don't like the Keithley Vis
  
• Both the NI gpib card and the Keithley gpib card work with VISA
  
• Below you can see the working vi. The command I used is the reset() in the vi.
  

[BrokenArrow]

All of these serial devices have idiosyncrasies that often just have to be shotgunned. Still looks odd to me, the Discard. Maybe Flush Buffer would work? But hey, if it works it works! :thumbup:

If you can't string together your commands with ";" or CR/LF (the typical method), you could still combine your Serial Writes with a For Loop.

Congrats on the success, thanks for checking back in.

[Rolf Kalbermatter]

QUOTE (BrokenArrow @ May 9 2008, 12:59 PM)

All of these serial devices have idiosyncrasies that often just have to be shotgunned. Still looks odd to me, the Discard. Maybe Flush Buffer would work? But hey, if it works it works! :thumbup:

Flush Buffer will delate data already in either the receive or transmit buffer. Discard Event will discard any events that might have already been queued for the current refnum. That are two very different things.

Rolf Kalbermatter

[BrokenArrow]

QUOTE (rolfk @ May 13 2008, 03:20 AM)

Flush Buffer will delate data already in either the receive or transmit buffer. Discard Event will discard any events that might have already been queued for the current refnum. That are two very different things.

Rolf Kalbermatter

Rolf,

Indeed they are different, I didn't mean to imply that they were similar, but does it make sense to create an event and immediately discarding it as this example is doing? The reason I suggested the Flush was, if the hardware were filling the buffer with "stuff" by the time he got around to doing the next Read/Write there would be trash in the buffer, so a tabula rasa would make the reads clean. I thought maybe whatever the Discard is asserting on the line might be analogous to clearing the line, but it isn't - thanks for the clarification