Skip to main content
Waters

Problem with linked calibration files in MassLynx - WKB95695

Article number: 95695

SYMPTOMS

  • Samples are run with a tune page specified in the sample list and a calibration file linked to the tune page.
  • The linked calibration is not applied. Instead, the samples are incorrectly calibrated using the existing instrument calibration, resulting in a reduction in performance for all the samples in the list that use that specified tune file.
  • After acquisition, if the data file is opened, the Experimental record shows that the wrong calibration was applied to the data.
  • This issue is likely to occur where users are running samples that use two or more tune files, each specifying a different calibration, where a new project is created and used each day, or where samples are submitted from different projects.
  • The issue has been reproduced in house by GSS. The problem is that sometimes when a tune file is generated with a linked calibration, the link does not work correctly under certain circumstances. When a tune file is "broken", it will remain broken, and the issue will continue, even if the tune file is moved to a different project.
  • The error occurs are when the tune file specified in the sample list is already open in the tune page, AND the existing instrument calibration (in the tune page) is different from the linked calibration specified in the tune page. These circumstances are created under the following conditions (for example):

1. User runs samples that specify tune page A linked to calibration A, followed by samples that specify tune page B linked to calibration B. At the end of the batch, Calibration B remains loaded. 

2. User creates a new project based on a template project. The current tune file for the template project is tune file A. As a result, tune page A is loaded into the tune page. However, this does not change the loaded calibration, which is still B. 

3. User prepares new sample list in the new project. Note that the current calibration is still B, and the current tune file is now A.

4. User runs samples that specify tune page A linked to calibration A, followed by samples that specify tune page B linked to calibration B. The link in tune file A is broken, so calibration A fails to load. As a result, all samples in the batch are run using calibration B.

 

ENVIRONMENT

  • MassLynx 4.2, Xevo TQ-S with SCN 986 and SCN 997 and (most likely) SCN 950
  • MassLynx 4.2, Xevo TQ-S micro with SCN 1001
  • MassLynx 4.2, Xevo TQD with SCN 855 or SCN 985
  • MassLynx 4.1 Xevo TQ-MS with SCN 876 or SCN 905 and (most likely) SCN 950

Probably other systems

CAUSE

Software defect, fixed in SCN 997. 

Prior to SCN 997, loading a new project opened the associated tune file but did not load the calibration that was linked to the tune file, whereas manually opening the tune file did load the calibration. 

In SCN 997 an later, loading a new project opens the tune file and also loads the linked calibration, making the system much more robust. 

FIX or WORKAROUND

If the issue is seen in releases prior to SCN 997,either:


1. Open the template project, and in the tune page, open tune file B. Then open whatever project was open before.
This will ensure that tune file B is the current tune that is associated with the template project—so whenever the template project is used to create a new project (step 2 above), tune file B will be loaded. This means that calibration A is correctly loaded at the start of the batch.

Or

2. Open tune file A (the one that has the broken link to calibration A) and choose File > Save As. Change the name of the file. Also update the name of tune file A that is referenced for samples in the template sample list located in the template project. This means that calibration A is correctly loaded at the start of the batch.

 

Test both of these workarounds using steps 1 through 4 above, running a single sample for each specified tune file.

ADDITIONAL INFORMATION

One of the above affected customers upgraded to SCN 1040 and reported that the issue occurred once more. However, it seems to have been a 'one-off' and could not be reproduced in-house. See Compass Case 03278125. 

 

id95695, A-SQ, MLYNX, MLYNXV41, SCN1001, SCN1040, SCN855, SCN876, SCN905, SCN950, SCN985, SCN986, SCN997, SQD2, SUPMM, XEVOG2XSQT, XEVOTQ, XEVOTQA, XEVOTQA, XEVOTQD, XEVOTQDIVD, XEVOTQIVD, XEVOTQS, XEVOTQSCRO, XEVOTQSIVD, XEVOTQSMIC, XEVOTQXS, XEVTQSMIVD, XEVTQXSIVD

Not able to find a solution? Click here to request help.