Re: [AMMRL] Lock drop and 2H channel error #Troubleshooting

From: Michael Groves via groups.io <mgrovesnmr=yahoo.com_at_groups.io>
Date: Thu, 29 Aug 2024 20:37:56 +0000 (UTC)

Not sure if this qualifies as sage insight, but here's what I would look at:

If you're trying to tune a Bruker RT probe on the lock channel, the motors
to do that don't exist.  There are screws on the barrel of the probe
that you can access if you pull the probe out of the magnet but the best you
can do for 2H on the lock channel is to wobb and have a look at the tuning
curve.  This doesn't sound to me like something associated with the lock
tuning changing.

If you keep getting the "invalid probe parameters" message then there could
be a problem.  But if not, it usually means that something is mis-set
in the software.  If I remember correctly frequently it has to do with
the pulse program.  Sounds like you got that cleared up.

Now--lock and BSMS issues.  I'm not sure if there's anything in common
between all these errors.  My first instinct is--if it clears up when
you reboot the keyboard, maybe try powering off the BSMS rack, disconnecting
the keyboard, and powering back up and restarting topspin and running cf. 
It's not unheard of that the keyboard can fail and cause problems.  And
if you power cycle the BSMS you generally need to restart the software to
re-establish communication.

Otherwise, there are a bunch of possibilities.  It could be a flaky
current source in one of the shim boards.  It could be a flaky H0 source
in the lock board.  It could be flaky lock pulses.  Actually that's
worth looking at too.  If you've got an oscilloscope you can connect to
the RF_OUT on the L-TX and look at the lock pulses.  If they are
consistent then that's fine.  If they vary a lot in amplitude then it
could be a flaky L-TX.   It could also be a flaky power supply in
the BSMS rack or a faulty CPU that's causing this behavior.

One thing you could try, although I think it's unlikely that this is the cause,
is to save an initial shim file when the lock signal is good, and then
when the lock drops, save the shim file then.  If there are changes in
the shims then we know that something weird is going on and changing the shim
currents and this could be a weird software glitch.   If not, we
can be more comfortable saying it's a hardware glitch.  

I thought I was done but I have some other stuff:  I would check the cooling
fans in the BSMS rack.  Probably the easiest way to do this is to open the
back of the console.  There's a duct on top of the BSMS rack that routes
the airflow out the back.  Get a scrap of paper and stick it on something--then
stick that in and hold the paper over the cooling fans in the BSMS rack. 
If the paper moves, the fans are running.  If a bunch of cooling fans are
not running and things are overheating it can cause strange effects.  It
can also cause board damage but hopefully it hasn't gotten to that point.

I think that's about it.  Those are things I would look at.   
This sounds like it might not be a trivial thing to troubleshoot.  =

Good luck.

Cheers,Mike


    On Thursday, August 29, 2024 at 01:52:39 PM MDT, Casu, Fabio (Fed) via groups.io wrote:

Dear all,  

Looking for sage insight into current issues with a Bruker AVII and RT probe.  
In May we had a lock dropping occurrence (see attached photo). A console reboot solved
whatever that issue may have been.  In August we shutdown the instrument in
prep for a tropical storm and now the issue is back with higher frequency and came along
with other problems.  After repeated console power cycles, repeated Topspin
cycles, cf, and ii,  several issues are occurring:  

- Invalid probe parameters found. This was not changed prior to shutdown. edprobe
detects correct probe.  Action: cleared the cable connections, set the connections
again, save. Seems to be ok, however see next bullet.  

- Error when testing 2H: 'channel can't be wobbled with this probe- no channel for : 2H'.
This should not be true. We were able to tune and match 2H during the May issue.  

- When reading in a saved shim file (rsh), the lock starts dropping somewhat similar to a
gradient experiment. Action: rebooting the BSMS keyboard fixes it - until trying to read
in a shim again.

- After a reboot, sometimes we can shim and run an experiment. But sometimes lock drops
during shimming,  Or drops as an expt starts,  Or drops while the system is idle.  

- Optimizing 01 in gs works intermittently. 

- Water suppression and resolution are terrible. 

- During cf, occasionally receiving 'Error reading BOOT firmware version
of BSMS-Unit: no error' and 'Error reading board config of BSMS-Unit, unknown command'.

Appreciate any advice or guidance offered.  Best, 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1575): https://urldefense.com/v3/__https://ammrl.groups=
.io/g/main/message/1575__;!!PvDODwlR4mBZyAb0!TSrcF-amOa8MBzz7ve0cDz3A0-DXfK=
OZcyFuZSu23T_y1MLiWfPilsqrbtkLJCSWBCaRzRAucSkeLPFxdztL9yi9yVeQ$
Mute This Topic: https://urldefense.com/v3/__https://groups.io/mt/108168223=
/7559972__;!!PvDODwlR4mBZyAb0!TSrcF-amOa8MBzz7ve0cDz3A0-DXfKOZcyFuZSu23T_y1=
MLiWfPilsqrbtkLJCSWBCaRzRAucSkeLPFxdztL9zpTSFRb$
Mute #troubleshooting:https://urldefense.com/v3/__https://ammrl.groups.io/g=
/main/mutehashtag/troubleshooting__;!!PvDODwlR4mBZyAb0!TSrcF-amOa8MBzz7ve0c=
Dz3A0-DXfKOZcyFuZSu23T_y1MLiWfPilsqrbtkLJCSWBCaRzRAucSkeLPFxdztL90r3oTj4$
Group Owner: main+owner_at_ammrl.groups.io
-=-=-=-=-=-=-=-=-=-=-=-




Received on Thu Aug 29 2024 - 13:38:04 MST

This archive was generated by hypermail 2.4.0 : Sun Sep 01 2024 - 15:22:33 MST