Just recently, on two different instruments, when we go to Analyze - Replace Calibration - for the CC, it updates the CC level, but DELETES one of the cal levels from every compound. It never did this before, and now we can't get it to not do it. Any h

We open and apply our latest .M file. Then when we try Analyze->Replace Calibration->All cmpds / CC level only, it does that update but drops a cal level from every compound. It is doing this on two different instruments. We've tried rebatching, running the CC from a brand new sequence, applying a method from a batch file where updating the CC does NOT cause a cal point to drop. We've gotten around it by Add Calibration->CC and then going into "Edit" Method and deleting the previous CC level line from EVERY compound... It never used to do this, and it its (thankfully) not doing it still on our Volatiles method with the twice the compounds!

We're not sure if something got corrupted or some setting got turned on inadvertently, or if there's some hidden column somewhere telling it to do that?! 

Simply confused!

  • Hello ,

     

    Based on your descriptions and tags this appears to be an issue with MassHunter Quant, correct? Which software revision and instrument version are you using?

     

    I will say in general if levels are being deleted when analyzing or updating curves it may indicate that that there is a mismatch between the levels present in the current batch and the levels present in the method being brought in. You may also want to make certain there are no mismatches in the level names. For example, I2, l2, and 12 may look similar, but if the names don't match exactly character for character between the batch table and the method then the level will not be used. 

  • So, we think we've figured out what it's doing, but still don't really understand why. And apparently we've just been lucky for the last 6 months that this hadn't happened yet?! Turns out the file number of the CCV we were using to Replace Calibration for CC is the same file number as Cal 2 on the instrument that then dropped Cal 2 and the same as the file number for Cal 1 on the instrument that proceeded to delete Cal 1 after updating the CC level. We generally always just use the same set of file numbers inside of the batch, as the sample names/IDs are always the different part. I've never heard in any of my training that you should never reuse a file name?? Is this really what it's thinking, or is our answer just as happy a coincidence as the file numbers being the same?!

  • As far as I know, Quant does not use the Data File name to determine how to process a given sample. As long as each sequence or worklist is acquired into a different folder then there should be no issue with using the same file names for each sequence or worklist, as long as all file names within a given sequence or worklist are unique.

     

    How a given sample is handled within the batch is determined by its sample Type and any assigned Level. I would suggest that you verify that your sequence or worklist is correctly assigning the Type and Level for each sample run. If you do find an issue there, the Type and Level can be corrected in the batch table. Otherwise you may want to try creating a new sequence or worklist from default, as it could be an issue with a corrupted sequence or worklist. 

  • The batch containing the CCV that we wish to use to replace the CC in the method is in a separate folder from the original calibration - also all names are unique (within that folder - again not unique to those used for the cal in its batch folder). I did the latest set of CCV response checks by creating a brand new sequence from default - to the same end...

    Types and levels were correct originally, were entered correctly and run in the new from default sequence, and I've created a new batch and deleted then re-entered the Type followed by the Level for each. Cal point is still dropped using any file number over 003.D (which was that start of the cal standards in the previously run calibration batch).

    For now we'll try always running cals with file names like "Cal1.D"... not sure what else could be causing this problem!

  • I have marked this question as Assumed Answered due to inactivity. Please let us know if you still need any help with this and we can pick it up from there

Was this helpful?