Vial leak using 7697A HS autosampler, but only when "Barcode Reading" is enabled

First off, it is not the barcode reading that causes the vial leaking, but my best guess is that the barcode reading introduces a variable time, that then can cause a scheduling conflict. This scheduling conflict is then not handled, and the 7697A is forced to remove the vial that is being pressurized, because another vial is arriving late to the oven.

The observed issue

Sometimes three vials in row are leaking completely, that is, the dynamic leak test reports leaks around 50 mL/min, and the recorded data is FID noise. Visible, these vials are fine and there is a visible needle puncture. If these vials are resubmitted for analysis, there is no leak issue and the FID signal is as expected, with front peak and then analytes and ISTD peak.

This issue is observed with our analyses of ethanol using HS-GC-FID. The relevant HS method settings are the ones affecting the sampling scheduling

Vial Equlibration 16 min
Injection Duration 0.5 min
GC Cycle Time 4 min
Fill Mode Default
Fill Pressure 6 psi
Loop Fill Mode Default
Extraction Mode Single Extraction
Leak Detected Continue

This is an infrequent issue we have observed as far back as 2014, with a 7697A (FW: A.01.05) coupled to a 6890 GC controlled using ChemStation B.04, all the way up to 7697A (FW: A.01.08.01) coupled to a 8890 GC controlled using OpenLab CDS v2.6. So I believe this issue is software independent.

Reproducing Vial Leaks

This works better with more HS vials, but the minimum to demonstrate this issue properly is 12 vials. The vials can be empty, but should not be labeled with a readable barcode.

Using the following HS method settings:

Vial Equlibration 15 min
Injection Duration 0.5 min
GC Cycle Time 2.5 min
Fill Mode Default
Fill Pressure 6 psi
Loop Fill Mode Default
Extraction Mode Single Extraction
Leak Detected Continue

The GC method is not important, but should (of course) not abort the run, so use 2 min or less run time, with constant oven temp. and constant flow.

Now submit the vials as a sequence first with barcode reading enabled, this run is expected to contain multiple vial leaks.

I've seen the third vial leaking on most runs, and seen runs of 36 vials, which repeated the pattern: OK - OK - LEAK - LEAK - LEAK - LEAK

I've not seen the first two samples leak, but only the last four samples are safe, since there are no vials entering the HS oven to interrupt their pressurization.

To ensure vials are properly capped, submit the same sequence with barcode reading disabled.

Video (Youtube): Agilent 7697A lowering vial into oven while pressurizing

Best guess of underlying issue

The short GC cycle time combined with every barcode reading failing (due to no barcode) seems to exacerbate the scheduling issue. I believe it is a scheduling issue, since a vial, "Vial X" will end up leaking when another vial, "Vial Y" is moved to the oven while Vial X is supposed to be on the sample probe.

In the activity log, the line "Vial Y moving from the shutter to oven position #" is observed between the "Vial X beginning extraction cycle 1 of 1" and "Vial X extracting" lines.

Based on Figure 5 in Agilent 7697A Headspace Sampler - Advanced Operation, Vial X should be on the sample probe between the log events: "Vial X beginning extraction cycle 1 of 1" and "Vial X purging".

In our routine method, using 16 min oven time and 4 min GC cycle time, the move to the oven of Vial Y when Vial X is lifted onto the sample probe is possible, since it would be the 4th vial, and the oven position of the sample probe and the shutter is offset by 3. However, with the suggested method for reproducing this issue, Vial Y should not be able to enter the oven (yet it does), since the oven carousel should be blocked from turning to the correct position, unless Vial X is lifted down from the sample probe prematurely, which would explain the vial leak!

Since this scheduling conflict only happens when barcode reading is enabled, it is likely linked to the variable time it takes to read the barcode. Note, the barcode reading does not have to fail for this issue to occur.

Possible solutions (ranked by perceived ease of implementation):

  1. Start the barcode reading of Vial Y earlier, so it will timeout and move to the oven prior to starting pressurezation of Vial X.
  2. Block the move to the oven, either let the vial stay in the barcode reader position, or put it back in the vial rack (and try again in the next possible scheduling window)
  3. Fix the retracting of the sample probe lifter, and use advanced oven position choice, such that Vial Y always can be placed in Vial X oven pos #+3, which would allow for Vial Y to enter the oven without disrupting Vial X injection.
Was this helpful?