FAQ:  Why do I get a "Stuck in a Reading Loop" error message when I run my EIS experiments?

A: This is a problem with some computer systems.  The message is the result of an Interrupt Overrun, as described below.

Symptom: At low frequencies, generally less than 0.1 Hz, an Error Message is displayed containing the warning "Stuck in a Reading Loop." The status line at the bottom of the runner window contains the message "Interrupt Overrun."

Cause:  An interrupt is a signal generated by a hardware device such as a Gamry potentiostat which tells the computer that the device requires attention. Gamry potentiostats generate interrupts whenever a data point has been acquired.  In particular, the EIS300 software generates data and interrupts the computer every 1.2 ms.  If the computer cannot read that data from the potentiostat before the next data point is taken, an "Interrupt Overrun" error occurs.

A computer’s responsiveness to interrupts is known as "Interrupt Latency".   Normally the interrupt latency of a modern Pentium II is on the order of 50-200 us, i.e., when a hardware interrupt occurs, it is serviced within 200 us.  However, old software, especially system software known as "device drivers", can increase interrupt latency by disabling the normal interrupt response for a long time.  When the EIS300 suffers from Interrupt Overrun errors some bad actor is disabling interrupts for more than 1.2 ms, or 6 times longer than normal.

 It is also possible that other software can increase interrupt latency.  Other software, especially programs created by Microsoft, may give the computer high-priority (e.g. non-interruptible) tasks to accomplish. 

Solution:  First the good news.  Version 3.2 of the EIS300 and Gamry Framework is much less sensitive to interrupt overruns.  Basically, it allows several overruns to occur before terminating an experiment instead of just one interrupt as in previous versions.  Version 4 is even more improved in this regard.  If, however, you don't wish to upgrade, perhaps you enjoy AVC (aggravation via computer), then here are some things to try.

Step 1:  Diagnose the overrun problem. 

To help diagnose overrun problems, we’ve created a special script called OVERRUN_TEST.EXP.  This script runs a curve similar to the calibration curves but it only reports points where an interrupt overrun occurs. 

Start OVERRUN_TEST and use an interrupt time of 0.001 sec.  Let it run for 24 hours. You shouldn’t see any data points in the runner window.  There should not even be a curve frame drawn since that is only drawn when the first point is taken.   If you have points and a curve,  you’ve had interrupt overruns.  Go on to step two.

If you don’t have interrupt overruns using OVERRUN_TEST at 0.001 sec timing but you still have problems running the EIS300, especially at low frequencies, call Gamry. 

Step 2:  Remove background utilities. 

Often there are background utilities that are running while EIS300 is running. 

Use Ctrl-Alt-Delete to bring up a task list.  OSA.EXE and FINDFAST.EXE often interfere with interrupts.  These are installed as part of the Microsoft Office Standard Installation and automatically start when Windows finishes loading.  OSA.EXE is responsible for loading the Microsoft Office shortcut bar and helping various Microsoft applications load and initialize faster.  FINDFAST.EXE is a notoriously unstable program that indexes your office files on your fixed drives for full-text content searching. 

You should remove FINDFAST.EXE and OSA.EXE from your Start Up folder.  While you’re there, remove the Microsoft Office shortcut as well.  After all, that silly bar just gets in the way most of the time.

Look in your Start Up folder at C:\Windows\Start Menu\Programs\StartUp. Remove any links to these utilities you see in there and reboot your computer.  Run the OVERRUN_TEST again as described in Step 1. 

Still having Overruns?  Weed out the other automatic startup utilities.  They are located in \windows\start menu\programs\startup.  You can move these icons to another directory.  Just as an aside, we’ve noticed that changing the name of the startup folder doesn’t work.  Windows seems to find it even if it is renamed.  Perversely clever, isn’t it?

Also remove or remark out utilities loaded from the AUTOEXEC.BAT and CONFIG.SYS files.  Use the SYSEDIT utility to get to AUTOEXEC.BAT and CONFIG.SYS.  Where’s SYSEDIT ?   From the Start menu pick Run..., and type SYSEDIT in the open field, then pick OK.   A multi-window Notepad like utility runs.  One window contains CONFIG.SYS and another has AUTOEXEC.BAT.

Reboot and check the task list again.  It should be much cleaner.  Rerun OVERRUN_TEST.

If you are still having problems, there are other places Windows can automatically load various utility programs.

Again using SYSEDIT, look in the WIN.INI file’s [windows] section for lines like:  run=... and load=... .  Remove these by putting a semicolon (;) at the beginning of the line..

Once you’ve removed everything you can in the utility section, reboot your computer and try running the OVERRUN_TEST again.  If the interrupt overruns at 1 ms have disappeared, try running EISPOT for an extended time.  If EISPOT now runs you can start adding back utility programs, rebooting, and running OVERRUN_TEST until you find the bad actor.  As we mentioned before, it is often an annoying Microsoft utility - maybe the one that animates the nauseating paper clip or some such thing.  Kill it!  Don’t let it load.  Do without!

If, when all the excess shrubbery is gone you still have an overrun problem, go to Step 3.

Step 3:  Updating your device drivers.    

Older device drivers may cause interrupt problems.  It is possible to use Window’s Safe Mode to install a plain vanilla group of device drivers.

To run in Safe Mode, reboot your computer and hold down the F8 key while it is booting - starting after the first BEEP.    You will see a list of operating modes.  Pick the Safe Mode and allow Windows to continue booting. 

Rerun  OVERRUN_TEST.  At this point, all should run correctly.  If not, you may have a faulty computer or an older computer which does not have enough horsepower to run EIS300. We recommend at least a 200 MHz Pentium to run EIS300 without any other extra tasks.  By the way, Windows 98 stripped down this way should run OVERRUN_TEST easily at 0.001 sec.

If OVERRUN_TEST runs OK now, you should go through the list of device drivers and get the latest versions from the manufacturers or from Microsoft.  These are often available on the Web.  You should look for drivers that are WHQL (Windows Hardware Quality Lab) certified.  If these are unavailable for an older device, a video card, for example try using Microsoft’s standard VGA driver from the Standard Display Types pick-list during the device driver selection process or replace the device with a more current model which has WHQL drivers.

Look for the latest drivers for A) Video Cards, B) Hard Drive Controller, C) Bus Master, D) Ethernet NIC. 

There is a utility program in Win98 called SYSINFO.EXE that can give you a list of the current driver set.  See if there are any other drivers that are out of date.

Step 4:  Some other things to try

1)    Power Management.  Turn off all the Power Management features so that all portions of your computer stay powered up at all times.  Re-boot your computer and enter the BIOS setup program (observe monitor during power-up to determine Hot Key).  Go to the Power Management Section and disable all power management features so that all peripherals stay ON while the computer is ON.

2)    Turn off display hardware acceleration.  From the Control Panel select Display -> Settings -> Advanced Properties -> Performance. Set the Hardware Acceleration slider to "None".

3)    Disable the Screen Saver, as they can tie the processor up needlessly.

4)    Disable any Anti-Virus applications that may be active.  If this works, try adjusting the application’s settings to allow for manual scanning only.

5)    Network Interface Cards and their supporting drivers may also play a part in inducing interrupt overruns. You should remove the NIC driver completely to see if it is causing the problem. Heterogeneous networks with more than two protocol stacks are notoriously balky. Also try getting the latest NIC drivers from your vendor.

6)    Some peripherals such as removable storage devices that use parallel, serial, or floppy controller interfaces or PCMCIA adapters to interface with digital imaging devices may also cause latency problems.  You should stick with the computer’s embedded IDE controller for such devices.

Step 5:  Give up!  

Once you’ve installed the latest device drivers and have eliminated any background utilities and you still have a problem -- you can call Gamry so we can try to figure out the problem.  If it is a machine not purchased from Gamry, there will be a repair charge.  You must send the computer to us with all of its hardware. 

 



Home | Products | App Notes | Sales | Contact | News | Support | Search

Batteries | Fuel Cells | Corrosion | Paints & Coatings | Physical Electrochemistry




Gamry Instruments © 1997-2009
  
Last revised on Wednesday, December 17, 2008