I unfortunately won't have access to my 2700 again until after the Christmas break but I do agree with cymreig in that an NI-Spy (also known as NI I/O Trace) capture would help show us all of the function calls that occur before the timeout error.
I also did a quick search for firmware on the web and the only firmware I'm seeing listed on the Keithley website is B9. Do you happen to know the history of this instrument and how it got this firmware version? VISA timeout errors like the one that you are experiencing usually mean that the instrument has somehow gotten into a bad state and has become unresponsive to the LabVIEW program.
Here are a few questions that I've got:
1. Could you send us an NI Spy capture of the error occurring? Although it could help to see the capture with the immediate error, I would rather see the error situation where it works for multiple iterations and then fails.
2. Can you try downgrading to B9 firmware on your instrument? Since it sounds like the instrument is causing the timeout that you're experiencing, trying a different (and hopefully more stable) version of the firmware could possibly fix the issue.. Here's the link to the download page: http://www.keithley.com/products/data/datalogger/?path=2700/Downloads#2
3. Sometimes when instruments become unresponsive and give these timeout errors they will give an error message on the front panel of the instrument itself. Could you try forcing the error and keep a close eye on the front of the 2700 and let us know if an error message is displayed? If something comes up then perhaps Keithley can explain to us why this particular error is occurring.
I hope this helps and have a nice holiday!
I purchased this instrument last week, this is the first application we will use it for. It came from Keithley with B10 on it. After you mentioned firmware yesterday I spoke with Keithley and they sent me their current firmware, I updated the instrument just in case there was some issue.
I noticed an interesting thing yesterday while I was testing things. In an effort to see exactly which sub VI was generating the error I highlighted the operations. The first time I would run the VI in this state it would seem to run ok. Running it a second time (immediately after, no changes) would cause errors to crop up again. I attempted to recreate that this morning. I used the Continuous Multi Read VI. The NI Capture files are attached as well as a screen shot for the first run.
Scan list 101:103
Results: The Keithley reset and never went into 4-wire mode, it stayed in default VDC mode. Error screen appeared.
Attached Screen Shot "NI Spy error"
Attached NI Spy Capture "2700 Continuous Multi Read Capture"
No Settings Changes
Results: VI ran as expected and captured 56 readings. By ran as expected I mean te Keithley entered 4-wire mode and scanned the requested channels.
Attached NI Spy Capture "2700 Continuous Multi Read Capture 2" Lines 31-114
No Settings Changes
Results: VI ran as expected and captured 72 readings
Attached NI Spy Capture "2700 Continuous Multi Read Capture 2" Lines 115-212
No Settings Changes
Results: VI ran as expected and captured 35 readings
Attached NI Spy Capture "2700 Continuous Multi Read Capture 2" Lines 213-488
2. I will talk to Keithley today and see what they say about downgrading. It's a good idea I just want to make sure that the B09 is compatable with my hardware.
3. It's interested that I tried to recreate the exact circumstances that guaranteed me an error yesterday and didn't get one. The insturment was turned off all night so maybe it went back to some default setting. Seems unlikely though since I reset it to factory defaults yesterday before trying things. Yesterday I wasn't seeing any errors on the Keithley when I was testing the Cont. Multi Read VI, it just never responded and stayed in VDC mode like the first run today. It seems that slowing down the LV gives the Keithley time to respond. I will continue to work on this over the weekend and see what I can get.
Thank you again for all of your help, I hope you have a good holiday.
P.S. I attempted to attach the actual trace file but the website will not allow it. I converted them to text files, if there is a problem with them let me konw.
I spoke with Keithley and they sent me the B09 file as well as the release notes. The only difference between B09 and B10 is two bug fixes. They fixed the display going blank if buttons are pressed during power on sequence and stopped the 2700 from freezing when switching to the Freq or Period functions. They said that the reason that the B10 is not on the website is because the website gets updated very slowly. I think for the time being I will stick with the B10 since I am able to communicate. Perhaps the NI Spy captures will help tell us why it's timing out.
I ran the Cont. Multi Read VI a few more times trying to recreate the error. I restarted NI Spy and have the capture for each run in the set. There were no setitng changes from my last post and highlighting was turned off.
Scan list 101:103
Ran as expected, took 26 readings NI Spy lines 1-211
Turned power on 2700 off and on to restart it
Same VI settings
VI stop button was accidently left activated so the VI started and stopped immediately. NI Spy lines 212-255
NI Spy File: 2700 Continuous Multi Read Capture 3.txt
Set the VI Stop button to true and ran the VI. NI Spy Lines 256-284
Error with no readings taken. 2700 Reset and stayed in VDC mode, talk indicator stayed on 2700 display
Waited some time and ran VI with no changes
VI ran as expected, captured readings for a few minutes and stopped with VI Stop button. NI Spy Lines 285-2757
Waited again and ran VI with no Changes
Error with no readings taken.
Screen capture Continuous Multi Read Error 4.jpg,
NI Spy file: 2700 Continuous Multi Read Capture 4.txt
Hopefully the NI Spy captures and the events will show something to you that I am missing.
I began to notice a trend when the 2700 would give an initial error and not make any readings. It seemed that if the meter was in it's default, start up state the VI/meter would function properly. When the meter had taken readings and was in the 4-wire state, which the VI leaves it in, I would get an initial error.
While I was testing this idea it seemed to be holding until I was running the VI, it was recording data and I got an error. This is what I think you wanted to see, luckily I was running NI Spy while it happened. I have two screen captures, one has the beginning of the NI Spy run and one has end of the NI Spy run. The whole NI Spy file is attached, lines 302-432 are from the run when I got an error while collecting data.
I went ahead and upgraded my unit to B09 from the old B05 firmware that this driver was originally tested with. Fortunately (or unfortunately, depending on how you look at it...) it seems that I can run the Continuous Multi Read example repeatedly without any errors or problems. From looking at the NI Spy captures and screenshots that you've sent me so far, it does look like your instrument is somehow locking up and which is causing the timeout errors. These types of timeouts are usually caused when the instrument gets in a bad state and becomes unresponsive. Here are a few questions that I've got:
1. Did you try changing the firmware of the device to B09 instead of B10? The locking up that you're describing could possibly be caused by firmware that was somehow corrupted. You may have already reflashed the firmware but I wanted to be sure that you had tried this as I am now using B09 without problems and I want to make sure we're both using the same firmware and driver software before we continue with further troubleshooting.
2. When you get these timeouts it is possible that the instrument could show an error number or message on its screen that could explain what is causing the problem. Could you try and force the timeout error again and keep a close eye on the instrument and let me know how it responds when this error occurs?
Let me know and we'll take it from there.
Thank you for keeping on this with me.
I spent the weekend and the last few days working on this and had made some headway just sending SCPI commands via VISA architecture. I put in time delays in order to let the 2700 reset, scan, etc. Everything seemed to be going well until the system would reset when I would send a read command. Not sure why this began to happen.
Since you got it working on B09 I decided to downgrade the firmware. I opened the Continous Read Multi example and ran it. It didn't work. I have attached the screen shot below (first jpg). The 2700 reset but did not enter into a scan mode.
The front display on the 2700 underwent it's reset screens and then entered it's default settings. The remote and talk icons appeared, other than that the screen indicated nothing. It remained in it's default settings until the error message appeared.
As a secondary test, I reinstalled the KE27xx driver set. Power cycled the 2700 and ran the Cont Read Multi again. The result was identical and I have attached the screen shot (second jpg). At this point I am kind of at a loss as to what it going on.
Thanks for the extra screenshots. From looking at the screenshot of the error that you're receiving, it looks like the error is happening on the VISA Read inside Error Query>Error Query Multiple>Clear Data Buffer. The Clear Data Buffer command is very basic and is used in many examples throughout the driver. One point to make is that this happens before the Function is set to 4-wire mode. Could you try running the example with Function set to DC Voltage and see if you see the same behavior? You previously said that the instrument functioned without problems in DC Voltage mode so I wanted to check this one more time.
At this point, though, I honestly think that we'll need the assistance of Keithley to really isolate the problem. Since I have a unit running identical firmware that is being controlled by an identical LabVIEW driver, it's now safe to worry that there might be something wrong with the instrument itself. I would recommend contacting Keithley and asking them if they could try running this LabVIEW Continuous Multi Read example on an identical unit and see if they also experience similar problems. If they don't have their own LabVIEW license, then they can easily download a free trial from our website (www.ni.com/labview). If they have units that are having issues being programmatically controlled, then I'm sure they will want to get to the bottom of it. Here's the information on my device (which works with the driver) just in case the serial number gives them any helpful information in figuring out the problem:
Let me know what you hear back.