i like this post (click again to cancel)
0
i dont like this post (click again to cancel) remove favorite mark from this question (click again to restore mark)

I have pulse programs which work great on our varian INOVA instruments, but when I transfer them to varian VNMRS I get error messages and/or decreased signal. Have any of you encountered this problem? I would really appreciate any ideas of what needs to be changed in the pulse program to make it VNMRS compatible. Thank you in advance!

asked Oct 19 '11 at 14:29

mikaelastewart's gravatar image

mikaelastewart
11


3 Answers:
i like this answer (click again to cancel)
1
i dont like this answer (click again to cancel)

The only significant change in going from INOVA to VNMRS (really from Sun to Linux) is that Linux requires psg_abort instead of abort. Just replace all abort statements with psg_abort and the sequences should compile. BioPack sequences work on Unity plus, INOVA and VNMRS (as well as the new DD2).

Performance should be identical, but since you are comparing different consoles it is likely that the difference lies in calibrations.

George Gray, Agilent Technologies

link

answered Oct 23 '11 at 10:01

georgeg's gravatar image

georgeg
301

updated Oct 23 '11 at 15:06

Evgeny%20Fadeev's gravatar image

Evgeny Fadeev
5771

Looks like the emailer or something removed the underscore in psg_abort. Replace all "abort" statements with "psg_abort". Make sure an underscore is between psg and abort. -George Gray - georgeg (Oct 23 '11 at 10:02)

i like this answer (click again to cancel)
0
i dont like this answer (click again to cancel)

To follow up a bit on George's answer, I've had problems in the past with calibrations. In my experience, the single most important parameters to calibrate for BioPack or any other sequence that calculates pulses "on the fly", aside from having good "hard" 90 degree pulses, are the amplifier compression factors on 1H (comp/compH) and 13C (compC). If these aren't good, your shaped pulses and decoupling will be off. Also, make sure you optimize you gradient pairs if the experiments are gradient selected. A seemingly small mismatch can cause severe attenuation. I just array gzlvl2 in a range a couple hundred units to either side of gzlvl1 and pick the strongest signal. Both of these are hardware rather than software dependent.

Also, as George said, if these are your own or third party sequences, changing abort to psg_abort should let the sequence compile. There are a few other commands you should update, but I've never had a sequence not run with the old syntax. In particular, any statements involving TODEV, DODEV, etc. should be updated, e.g. rlpower(tpwr, TODEV) should be changed to obspower(tpwr).

link

answered Oct 26 '11 at 07:46

Andrew%20Fowler's gravatar image

Andrew Fowler
96

i like this answer (click again to cancel)
0
i dont like this answer (click again to cancel)

I traced the error message to the need for explicit blank and unblank statements for a carbon decoupling pulse. The pulse sequences would compile and run but returned an error message when ran. The signal to noise issue was likely a hardware issue related to 2H decoupling that I found with George's help. Thank you for your answers.

link

answered Nov 02 '11 at 08:15

mikaelastewart's gravatar image

mikaelastewart
11

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a good answer, for discussions, please use comments and please do remember to vote (login to vote)
toggle preview

Tags:

×1

Asked: Oct 19 '11 at 14:29

Seen: 5,849 times

Last updated: Nov 02 '11 at 08:15

powered by CNPROG