Probleme beim Beenden einer Sequenz am 7T von Siemens

[Badmintron]

Liebe Community,
ich nutze PyPulseq zur Sequenzprogrammierung und bin bei der praktischen Anwendung am 7T von Siemens auf ein Problem gestoßen. Ich habe die klassiche TSE Sequenz aus dem Repository genutzt und davor ein paar Blockpulse geschaltet (mit dem Ziel T1ro imaging zu betreiben). Nun habe ich dementsprechend die Dauer des Spin-Locking Pulses variiert und festgestellt, dass in Abhängigkeit von der SL-Dauer einige Sequenzen vom Scanner nicht ordnungsgemäß beendet werden. Es wird dann noch 0s aber 10% Rest angezeigt und wenn man nicht irgendwann das System neu startet, passiert nichts. Allerdings klappt die Datenaufnahme auch für diese SL Zeiten – es ist also nur das Problem, dass der Scanner nicht zu „verstehen“ scheint, dass die Aufnahme nun beendet werden kann und er in der Arbeitsabfolge weiter machen kann (oder erst einmal nichts tun, wenn nichts vorgesehen). Gibt es die Möglichkeit in PyPulseq einen Befehl hinzuzufügen, der dem Scanner verständlich macht, dass dies das absolute Ende der Sequenz ist und er nun die Aufnahme abschließen darf? Ich würde mich sehr über jegliche Hinweise oder Ideen freuen!

[schuenke]

Hallo. Generell ist es besser die Fragen hier auf Englisch zu stellen, damit der Pool an potenziellen Helfern etwas größer ausfällt. Meine Antwort werde ich aus gleichem Grund deshalb auch auf Englisch verfassen:

If I understand correctly, your pulseq spin-lock sequence sometimes doesn't stop / finish the acquisition.

There is no specific command to tell the scanner to stop the acquisition because this should not be needed. If the scanner reaches the end of the file, it should stop. Did you maybe add a trigger somewhere so that the reason could be that the scanner is waiting for a trigger signal?

If it is really a bug, it would be interesting to know the exact sequence and especially the exact spin-lock times when this happens. As far as I know, the maximum pulse duration of a single rf pulse @ Siemens scanners is still 100 ms. Did you maybe exceed this limit?

[schuenke]

I was (unfortunately) able to reproduce this error yesterday night when measuring at a Siemens Skyra under XA30 using a TIRGGERED MRF sequence. When running the sequence without selecting a trigger in the physio card, the sequence was running but then didn't finish showing 0 seconds, but 10% left. Only a hard reset could help.

When running the same sequence but selecting an ECG trigger, everything worked fine.

Interestingly, the exact same sequence works at all other scanners under software version VE11c, XA50, XA61 (and pretty sure it also worked on our old scanner running under VB17) when NOT selecting a trigger. So maybe a bug in pulseq under XA30? Would be interesting to know which software version you were using @Badmintron

[Badmintron]

Sorry for replying so late! We currently use the Software Version XA60. Maybe it really is a bug in pulseq and the occurance of the bug depends on the used Software version (although obviously you produced the error for XA30 and I using XA60 but you did not when using XA50 which seems strange)?

[schuenke]

Can you confirm that it only happened when using a Pulseq sequence involving a trigger, but not selecting a trigger in the Physio card? Or did it happen in other cases as well?

[Badmintron]

I tested again today and unfortunately also selecting a trigger did not help to properly end the sequence in my case.