[Automated-sequencing] Re: DNA SEQ: 3730 Tray on Deck errors

Phillip San Miguel pmiguel at purdue.edu
Wed Sep 6 09:58:07 EST 2006


 > At 12:24 AM 6/09/2006, Phillip San Miguel wrote:
 >>     [Just to widen the pool of 3730 users, this is a cross post to
 >> ABRF forum and bionet.genome.autosequencing]
 >>     There has been some prior discussion of a particular error that
 >> has bedeviled our facility more and more of late:
 >>
 >>http://www.bio.net/bionet/mm/autoseq/2006-August/thread.html
 >>
 >>     The error is "Tray on deck does not match tray type in run
 >> setup". For us, this generally occurs between the A1 and B1 quads
 >> of a 384 sequencing reaction plate. Generally, once it occurs, we
 >> are shut down until and engineer fixes it. We have two 3730XL's and
 >> have actually seen this on both instruments during the last month.
 >> The fix is generally for the ABI Field Service Engineer to replace
 >> all the sensors in the gripper assembly.
 >>     Usually this seems to do the trick--for a time.
 >>     The FSE will almost universally warn us that sensors can be
 >> damaged by liquids being spilled on them. But then just as
 >> universally note that there was no evidence that this had occurred
 >> with our sensors. (The sensors are dry and have no buffer residue on 
them.)
 >>     The situation is somewhat more complex than I'm describing
 >> here--frequently this error seems to presage the failure of some
 >> major system of a 3730. But not always.
 >>     Has anyone else been seeing sensor issues in their 3730's?
 >>
 >>--
 >>Phillip SanMiguel
 >>Purdue Genomics Core Facility
> Date: Wed, 06 Sep 2006 10:24:32 +0800
> From: Frances Brigg <F.Brigg at murdoch.edu.au>
> To: ABRF Discussion List <ABRF at list.abrf.org>
> Subject: Re: DNA SEQ: 3730 Tray on Deck errors
> 
> We have had a 3730 since 2003 and have had to have most or all of the 
> gripper sensors replaced on 3 occasions since installation. The AB 
> engineers are always surprised and say that they don't see this kind 
> of thing at other sites. The sensors are always dry with no buffer 
> residue, and the replacement sensors are wrapped in plumbers' tape to 
> keep moisture out. After the most recent replacement the engineer 
> suggested that it could be due to power failures or brown-outs that 
> affect the sensors first, and this would probably explain why your 
> sensor failures sometimes precede major systems failures. What we 
> tend to see is intermittent failures with the sensors, so that they 
> will run fine for a while and then start to fail with increasing 
> frequency. If the sequencer is shut down for a while, it will again 
> start off OK but then fail once it has been running for a while (ie 
> after 1 or 2 runs). The engineer said that this occurs because the 
> sensors run better when cold and are more likely to fail as they heat 
> up, which could explain why they tend to go at a particular quad on a 
> 384 well plate. It is a good idea to run the sequencer beforehand if 
> an engineer is coming out to look at the sensors to make them fail on 
> cue, as it often takes an hour after switching on with active runs 
> for them to start failing.
> 
> The error message will depend on which particular sensor goes and at 
> which point in the process it fails, so you could also see messages 
> such as "autosampler cannot hold tray" from the same problem, and 
> find the autosampler holding two plates at the same time. I have on 
> some occasions left the sequencer on and gone back to find the 
> capillaries sitting in air as the periodic automatic re-homing of the 
> autosampler has started and a sensor has failed in the process. It is 
> possible using the 3730 service tools/service/diagnostic/autosampler 
> test to do a dry run (ie it does all of the plate movements in a run 
> without the polymer fill and electrophoresis) to work out which 
> sensor is failing when not all of them are affected, but if they all 
> go there is not much you can do, and it only really helps if you can 
> persuade your FSE to leave you a spare sensor or 2 for emergencies.
> 
> The engineer also said he had seen errors at other sites where the 
> sensors were fine but the bottom of the plate holders were filthy and 
> so encrusted with buffer that it formed a wall where there should 
> have been a cut-out and made the plate appear to be a different type 
> than it was. (It is a good idea to examine the base of the trays to 
> see if there is anything unusual about them, particularly in the area 
> that the sensor is having trouble with if it is the same plate holder 
> and sector each time).
> 
> Finally, I have also seen software problems cause apparent sensor 
> errors, but only in a very unstable system. (Our FSE did the upgrade 
> from V2.0 to V3.0 for Windows 2000 and couldn't get it to work, we 
> opted to wait until the XP version came out rather than trying to get 
> the Windows version reinstalled properly from scratch, and hobbled 
> along with a partially restored V2.0 but with bits and pieces of V3.0 
> installed. The overnight runs were fine, but during the day we kept 
> getting sensor errors. After a while we noticed that they occurred 
> whenever the in-stack door was opened during any part of a run, 
> apparently triggered by the StackerMsgBean "%% an instrument door is 
> open" error message, and whatever stage the run was at it would fail 
> the next time the autosampler tried to pick up a plate. Normally it 
> isn't a problem to add to the in-stack with runs in progress, 
> although the %% error message still appears. We would find that the 
> error would also keep recurring if we tried to repeat the run using 
> the same plate record, but if a new plate record was made up with a 
> different name and the door was left alone it would run perfectly 
> well. This took a long time to diagnose, because there was sometimes 
> quite a long gap between opening the door and the error that it 
> triggered, eg while the oven was getting up to temperature during a 
> run, but once discovered the error could be generated on cue every time.)
> 
> But sensor damage due to power fluctuations is the most likely cause 
> of ongoing problems.
> 

Thanks for the detailed response, Frances. I'm also starting to hear 
that the reoccurring problems I'm having are likely the result of power 
fluctuations or spikes. (With suggestions that I should purchase a 
UPS/power filter.) Of course it is very difficult to rule this 
possibility out, or it would be. I think I *can* rule this out because 
one of my 3730XLs *is* on a UPS/power filter. Actually it is the one I 
have had the most trouble with sensor-wise.

Anyway, the Field Service Engineers no doubt have a hard job here. The 
3730 is a complex instrument. But I have to admit that after a while I 
get a little tired of hearing the standard list of culprits for 
instrument failures:

(1)	I'm sloshing buffer or other liquids on the plate type sensors.
(2)	Someone/something is accessing my console computer through the 
internet in a way that causes mysterious failures.
(3)	The power to the instrument is bad.

-- 
Phillip



More information about the Autoseq mailing list