LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why is my source memory sweep running twice? ** Keithley 2400 ** SCPI **

Solved!
Go to solution

The error only occurs when the VISA write is followed by a VISA read.

0 Kudos
Message 11 of 24
(1,155 Views)

I have found that when I pause the VI just after VISA write, it only sweeps once. Then when I continue it, another sweep is performed at VISA read. I don't know what this means yet but its a start. 

0 Kudos
Message 12 of 24
(1,150 Views)

In spy, I have tracked the command that causes the second sweep. It is this:

> 34. VISA Read ("GPIB0::24::INSTR", 100000, "-5.250000E-01,-5.9014...")
> Process ID: 0x0000122C Thread ID: 0x000013A8
> Start Time: 14:10:53.411 Call Duration 00:00:04.196
> Status: 0xBFFF0015 (VI_ERROR_TMO)

 

The 100000 comes from the byte read value I wired to VISA read, I used a random large value so that it wouldn't cut off any values.

 

Any thought?

0 Kudos
Message 13 of 24
(1,149 Views)

Why are you setting the timeout and closing the VISA resource in your subVI that does the reading?  This causes these things to happen every iteratin of your loop.  While I don't think it is directly causing your problem, it definitely is a bad idea to do this stuff repeatedly in a loop.

0 Kudos
Message 14 of 24
(1,142 Views)

I did both of those things in an attempt to fix an error I was getting with multiple VISA read sessions. I was getting a timeout error becuase the VISA sessions were not ending properly after each sweep. So that is why I have a VISA close at the end of each session and a VISA clear at the beginning. The timeout setting is not important. I have not experimented with getting rid of either VISA close or VISA clear.

 

Why is it a bad idea to repeatedly do this?

0 Kudos
Message 15 of 24
(1,136 Views)

You open a VISA session and configure it once.  You do what you need to do repeatedly in a loop.  You close the session once at the end.  Repeatedly configuring and closing in the loop is a waste of time and resources.

0 Kudos
Message 16 of 24
(1,134 Views)

Hi,

 

Are you getting the double read each time "sweep voltage" sub VI runs?  So double reads once in each of sequence frames 1 and 3 ?

 

Looking at the write/read sequence in "sweep voltage" sub VI I would probably put a short time delay between each of the three writes.

 

I am assuming that the instrument takes a measurement/sweep when the third write occurs, when the INIT command is sent.  And that another measurement/sweep ( only indicated on the instrument ) occurs when you perform the read. Is this correct?

 

Is the returned string from the read correct? 

 

***

 

In MAX did you sent the init and then perform a read?  You saw the instrument take measures only when the INIT was sent?

 

***

Generally the sub VI looks correct. Write then read.  Hard to tell what state the instrument is in, you are not using an initialize, and you are opening and closing the reference to much, as said above.

 

There seems to be a lot on the table, so to speak. 

 

You might set up the script in the instrument and run the "voltage sweep" sub VI in stand alone mode to test for the error, and also to look at some of the init properties for your session.

 

Your descriptions have been good. 

 

-------
Mark Ramsdale
-------
0 Kudos
Message 17 of 24
(1,132 Views)

Thank you for the tips on opening and closing the reference. I will clean that up once I have the sweep executing the correct number of times. 

 

Yes, I am getting a double read in sequence frames 1 and 3. As you said, this is indicated only on the instrument. When I highlight the execution, the VI moves on while the Keithley is indicating that it is still sweeping. The values that I get from the buffer are correct. 

 

Are you saying that you would put a delay in between :_SOUR:MEM:_POIN 1 and :_SOUR:MEM:_STAR 1  and :INIT ?

 

___

 

In MAX, i sent the :INIT command and then clicked read. This returned a correct string. The instrument only took measurements when the :INIT sent.

 

__

 

I have run the subVI alone and thats how I found where the error occurs. If I only send a VISA write with no VISA read, the instrument only sweeps once.

0 Kudos
Message 18 of 24
(1,125 Views)

Hi,

 

I took a look at the I/O trace and along with what you have stated.  It would seem to indicate the instrument has some issue, in that there are no extra commands.  But the MAX behavior seems to indicate otherwise. ( What about the temination character, are they the same in both)

 

In both MAX and the app you are getting the correct and complete reply from the instrument?  One read in the VI gives you the complete reply? 

 

How annoying is it to have the instrument take a second read? 🙂

 

Can a second read in MAX get any response?  When you write in MAX do you perform three individual writes, thus putting a delay between each write. What happens if you combine the commands in one string ( using the command separator character)

 

I was suggesting the delay as you asked.  Just wanting to make sure there was no issue writing to close to each other.

 

You seem to have covered most of the gotcha type errors. 

 

 

-------
Mark Ramsdale
-------
0 Kudos
Message 19 of 24
(1,117 Views)

 

>>How annoying is it to have the instrument take a second read? 🙂

 

I agree, but I am told it is important to only have one read for this application. If it were up to me I would stop here...

 

I am now working on the questions you have asked. 

0 Kudos
Message 20 of 24
(1,112 Views)