AGC and MaxIT not working for Orbitrap MS2 scans on Eclipse

[pisistrato]

As can be seen in the gif, when trying to replicate a MS2 scan on the Eclipse using the provided fusion-example-client example neither the AGC nor MaxIT are taken when placing the scan from the API

When the readout is set to the IonTrap it works as expected.

[jesse-canterbury]

Thanks for the report. Have you installed the patch for 3.5? You should be able to get to it here.

That said, I can see the issue on my side as well. However it works as expected when running a method acquisition "underneath" the IAPI application. I'll look into it.

[pisistrato]

Yes, the instrument is patched.

Indeed, the issue appears only when the scan is placed "directly" from the IAPI.

Thanks.

[t0mdavid-m]

We are having a similar issue with Tune 4.0 on Tribrid. Changing the AGCTarget has no effect on Ion Injection Time. We tried varying AGCTarget between 3000 (reported default) and 100000 (maximum valid value).

Therefore, I assume that this parameter is currently not working and some default is used instead. However, given that according to the tune documentation 100% normalized base value is equivalent to 400000 and 50000 for Full and MSn scans respectively (Orbitrap), the documented value range and default value are quite unexpected.

In order to ensure comparability between Tune and the iAPI I would like to enquire what AGC target values are used internally when measuring via the Orbitrap (i.e. what is the input that should be made to Tune in order to obtain an equivalent AGC target)?

Platform: Orbitrap Fusion Lumos Tribrid Mass Spectrometer + FAIMS Pro Interface

[jesse-canterbury]

Are you placing scans while running "on top" of Tune or while running a method? Placing scans while running on top of Tune still has problems; this issue has been deprioritized as the vast majority of users use the IAPI in conjunction with methods.

And what injection times are you seeing? Are they all the same, i.e., set to the maximum injection time?

[t0mdavid-m]

Thank you for the swift response!

We tried adjusting the AGCtarget on top of a Method and still does not seem to be working.

Setting AGCtarget to 3000 or 100000 did not change the IIT for both the iontrap and orbitrap mass analyzers. The IIT was also smaller than the maximum injection time (~50ms for FTMS with maxIIT=100ms).

[jesse-canterbury]

Can you attach your method here, so that I can try it as well?

[t0mdavid-m]

Below is the method we used:

method.zip

Over that method we used the fusion-example-client to trigger scans via the iAPI.

[jesse-canterbury]

Apologies for the delay. This appears to be related to how the fusion-example-client sends scans. It is sending scans with all possible values defined; normally one would make a scan with only the relevant parameters defined.

If you comment-out line 322 in Form1.cs of FusionExampleClient, and instead set the values yourself, for example using:

cs.Values["FirstMass"] = 400.ToString();
cs.Values["LastMass"] = 1400.ToString();
cs.Values["ScanType"] = "Full";
cs.Values["Analyzer"] = "Orbitrap";
cs.Values["ScanDescription"] = "Full400-1400";
cs.Values["AGCTarget"] = 5.ToString();

...and then for "AGCTarget" try different values (switch between 5 and 500,000 to see huge differences), you should see the injection times varying as expected.

Hopefully that will get you going. Probably there is still an issue here, which I'll continue investigating. Thanks again for the report.

[jesse-canterbury]

OK, after returning to this issue recently, and with the help of another user, we found that AGCTarget is working as intended for full scans, but other scan types appear to have a problem. The workaround is to use instead the "MSXTargets" parameter, like so:

cs.Values["MSXTargets"] = "10000";

And then continue using "AGCTarget" for full scans. This will be fixed in Tribrid series 4.2, due out this summer.

[pisistrato]

Thanks for the feedback, I can confirm this workaround works fine.

@jesse-canterbury off-topic question: to whom can I report a bug I discovered on the Exploris tune? It concerns a charge state decision tree DDA method. The method is compiled (i.e. it is saved as .meth), but it is not executed (i.e. an error appears when trying to submit the queue)

[jesse-canterbury]

@pisistrato I forwarded your note to the relevant folks on the Exploris team. They'll take a look & make a bug report. If I get any more info back, I'll update you. And feel free to ping me if enough time goes by with no news.

Glad to hear the workaround above works ok!

[jesse-canterbury]

@pisistrato Please email support.exploris.bremen@thermofisher.com with a full set of info about your observations, such as Exploris software version, your method file, the displayed error message, and steps to reproduce the error. And please let me know if I can help at all. Thanks!