3700 problems

Carrie Sougnez carrie at genome.wi.mit.edu
Mon Sep 11 11:03:56 EST 2000

   I have commented on the discussion below.

Phillip San Miguel wrote:

> Laurence Hall wrote:
> > [...]Of late, curious things have been happening with two of our machines :
> > In
> > particular, the autoloader has been crashing into the electrophoretic
> > chamber and damaging the loading tips. This has happened 3 times with one
> > 3700 and two times with the other; For each machine, ABI replaced the
> > autoloader head twice and recalibrated the offsets................yet the
> > problem persists.
> >
> > I am imformed by ABI in England that problems of this sort are recognised
> > as genuine and seem to correlate with use of the foil piercing module.
>     I'm not the best person to answer, but in case no one else does I decided
> to respond. We've done about 500 runs on our 3700 in foil piercing mode. During
> this time we only had one robot mishap--where the loading robot froze during
> loading[1]. Because of this, our service engineer gave us a program that was to
> be run before data collection is started called "port off.exe". I was told it
> turns off the diagnostic port (whatever that means.)
>     No problems of this type since then--but this isn't a large sample size. If
> any of the large sequencing groups (I'm thinking MIT, Whitehead here) have
> found port off.exe to be the answer to many of the 3700's problems perhaps they
> will comment.

The port off.exe should not have any effect on the robot.  It only has an effect on
the data collection software and data buffer- see below.  Your robot problem sounds
unrelated to the foil piercing.  At the Whitehead, we have had persistant robot
problems both before and after starting the foil piercing modules.   Having onsite
engineers helps alot to respond quickly to these problems. Most of the time it is
fixed with something simple as you described above (replace autoloader head, new
tips, calibration etc).  There are however instruments that have persistant robot
problems and have needed new robots.   We try to minimize the errors by doing the
following.  Inspecting the capacitance touch pads, and autoloader tips and cleaning
them if necessary to be sure the robot can get an accuate plate deck calibration.
We experiment with plates and plate bases to find the least error prone designs. If
an instrument has obvious foil piercing problems we will try to "sharpen the
fangs"  (with a file) on the foil peircing tips so that less presure is required to
break the seal, you may want to try that.  Did your instruments have any robot
errors before using the foil peircing modules?

>     Apparently foil piercing mode was not a recent addition to the 3700--beta
> test sites are said to have had early versions of if. Steven Lasky has reported
> in this group that autoloader failures were correlated with using foil piercing
> on beta-3700. However, presumably there were changes introduced into foil
> piercing mode before its field release in version 1.1 of the Data Collection
> software. As I note above, we've had more than 500 runs on our machine using
> foil piercing on 384-well plates.
>     One issue comes to mind with regard to autoloader failures being caused by
> foil piercing. The 3700 documentation for doing foil piercing suggests the use
> of a certain type of 3M foil tape for foil piercing. However, many labs
> probably had already in their possession a roll (or many rolls) of a thicker
> grade of foil tape used for plate sealing during alcohol precipitations and
> such. If this thicker foil tape were being used, then it might, over time,
> damage the auto loader. I had thought that the piercing fangs were simply
> unable to pierce this thicker grade of foil--but have recently inadvertantly
> discovered that this is not the case. Hence, one could be using this type of
> foil tape without immediate negative effects.
> > For another of our 3700's, the instrument will sometimes skip the first 96
> > well segment of a run; We routinely run 2 384 well plates at a time. In
> > addition, we have experienced other glitches such as machine jamming during
> > data collection and inability to quite data collection from the program
> > itself or from 'task manager'. Our thinking is to reinstall the collection
> > software.
> > [...]

The Port Off.exe does solve this "pausing out during data collection" problem. This
problem presents in the following way.  The instrument will usually run one
quadrant of a 384 well plate to completion, will get through to the data collection
portion of the second run and then stop collecting data.  The instrument appears to
be running fine (data collection says "collecting data", and the LED light is
green) but has actually stopped running (you can confirm this by looking at the
hyperterminal).  The port off.exe  is designed to turn off the diagnostics port so
that the data buffer (memory) does not get full during the run.  ABI software
engineers confirmed that this was the problem.  Data collection simply stops
because the buffer is full.  Turning off the diagnostics port solves this by not
allowing unnecessary data into the buffer.   Since installing and running the port
off.exe we have not had an instance of this particular error.  We are also testing
a new firmware version in which the ports are shut off automatically via a scpi
command  (and the technician no longer needs to run the port off.).  These
instruments have not had this problem in the two months since we have been running
the new firmware.

>     The "jamming during data collection" is the signature of the problem that
> he "port off.exe" script was designed to fix.
>     You don't happen to used run modules with different names on the same
> plate, do you? If so, the one that is first in the alphabet will run first[2].
> This might give the appearance of the quadrant having been skipped. But this
> should be obvious in the run schedule. Also, eventually the run should
> happen--just later in the batch. Unless you had the "maximum number of runs per
> batch" field in preferences set to less than the number of runs linked.
> Phillip San Miguel
> Purdue Genomics Core Facility
> [1] This mishap allows us to answer a question we never asked: "Can an array be
> recovered after sitting longer than 24 hrs with the oven on, the oven door open
> with no water covering the caps?" The answer is yes. Following the instructions
> of our service engineer, we able to restore the array with no blocked
> capillaries and have since performed several hundred runs.
> [2] Believe me, this is a feature, not a bug. In fact, this feature can be used
> to force the robot to load "nested" quadrants of a 384 well plate. That is, in
> the same way a 96-well pipetting device, such as a Hydra, addresses a 384-well
> plate, the auto-loader can be instructed to load. Hence you could load a
> 384-well plate with 96 samples *with a Hydra*  (leaving the other 288 wells
> empty, if you like). Why not use a 96-well plate? Well, for one thing, a
> 384-well plate is cheaper than a 96-well plate.  Also you can force the loading
> of 104 samples per run. I frequently run low-throughput samples (finishing
> reactions, for instance) along with high-throughput samples in this manner. I
> posted a description of this process to this group some time ago. Since then
> I've discovered you can schedule runs with big-dyes and drhodamines together.
> Because the 3700 employes a virtual filter set it is even possible to schedual
> different dye-set reactions in the same run (eg, E and F), should this be
> necessary...
> ---

Carrie Lynne Sougnez
Coordinator, Sequence Detection and Special Projects
Whitehead/MIT Center for Genome Research
carrie at genome.wi.mit.edu

More information about the Autoseq mailing list

Send comments to us at biosci-help [At] net.bio.net