AMMRL: Summary: Varian FIFO buffer underflow frequency and VT connectors

From: Kirk Marat <kirk_marat_at_umanitoba.ca>
Date: Fri, 28 Sep 2007 10:43:23 -0500

Thanks to all who replies to my query. For the FIFO underflow problem
it seems that piling up to many requests in the acquisition processor is the problem.
The main culprits seem to be:

- High oversampling rates
- Short delays
- Large NP values
- Complex sequences (We have a SpinCad TOCSY sequence and a CRINEPT sequence
   that would fail every time)
- Small BS values (1 is NOT a good value for BS !)

For the VT connectors, some recommended fixing the cable to the magnet leg to
reduce strain. Unfortunately, this won't work for us as we frequently have to move the
cable between the Chemagnetics VT stack at the top of the magnet and the liquids probes
at the bottom. We have the added problem that the Chemagnetics VT system has a
different pin-out on the connectors, requiring an "adapter cable" when using the liquids
probes. This doubles the number of connectors and the chances that one can go
wonky. I guess I'll just go on cleaning and replacing them until I get brave enough to
retrofit a different connector.

Here are the individual responses:

------------------------------------------------------------------------------------
 don't use (yet - gulp) VNMRJ 2.x on any of my Inova 68040 based
spectrometers. I used to have problems with FIFO on vnmr 6.1C until
the last (2006) update to that software but none since then. Three
spectrometers, no problems along that line ... I've been told that
I'm just lucky and that sooner or later... the sooner may come when
I upgrade into Linux and vnmrj offerings that still support 68040.

VT connectors - we have taken to replacing the Varian connector with
our own and that, as you suggest, helps to a point but isn't a
forever cure. I have a new electronics guy working for me and he is
very (very) good but hasn't had this brought to him yet. Let me
ask ... what we really need is a positive connection that is more
durable than the DB-9 and more practical than Varian's offering.

A related problem with VT is the lack of positive control exercised
when air flow is lost. Bruker's solution has always been to monitor
flow directly and shut power off to the heater if it fails. I think
that Varian's approach leaves much to be desired in this regard.
---------------------------------------------------------------------------------------
The FIFO problem is something that everyone using Varian sees every now and
then. The best solution to minimize it is to make sure that you don't
collect too many points. The usual culprit is that with dsp='n' or dsp='r',
any time you change sw or at, VNMR resets oversamp to the maximum allowable
value. Typically if you set oversamp down to something around 8 (or even 16)
for normal bio experiments you should rarely see the problem, but you need
to do this manually (or I suppose you could modify the go macro, but I don't
like doing that). What we think happens is that large for values of
(oversamp*np) the console doesn't have time to digitize the full FID before
the next transient, especially for shorter values of d1.

As for the other issue, the best I can offer is to minimize the strain on
the VT cable as much as possible. Sometimes cleaning the contacts helps for
a while, but I get the feeling you're past this stage.
------------------------------------------------------------------------------------------
we suffer from both of these problems.
With regards to the VT cables, yes they keep going bad because its
just a bad (weak) connector. Sometimes we have done clunky things
like attempt to lift the connector with a loop of string attached to
the magnet. When they have gone bad we just get new ones (usually)
or my colleague re-builds them.
We also see the FIFO problem intermittently on our Inova. No solution yet.
-------------------------------------------------------------------------------------------
The general consensus on the FIFO underrun error I got was to turn off DSP
with dsp='n'. It may be an issue of (mis)communications between the ADC
and the DSP mezzanine board.

For the VT cable, try fixing the cable to the bottom of the magnet with a
stick on zip-tie mount and a zip tie. Taking the pressure off the
connector on side-connector Varina probes seems to extend the life of the
connector.
--------------------------------------------------------------------------------------------
I have found that the FIFO underflows are exacerbated by particular pulse
sequences that have large memory transfers (more points). The transfer from
the buffer did not complete by the time the next memory block was ready to
transfer ... hence first in first out buffer underflow.

The relationship between acquisition time and 1st delay seems to be
critical. With d1 being too short being the problem.
I've read before that dsp='n' and bs='n' helps too.

Others have reported a myriad of console hardware issues that can cause this
error but if it happens usually on 2D or other high memory intensive
experiments ... I would suspect a parameter issue. I would look at the
experiments that do NOT have FIFO underflow and examine what is different
about them (or the accounts).
---------------------------------------------------------------------------------------------
we simply do an "su acqproc" in terminal window, then push the red reset
switch on the CPU in the console, wait 10 secs, do su acqproc again. <We do
this each Monday and thus avoid nearly all FIFO errors which are caused by
probelms in a Motorola chip in console that loses communications after a
while i.e. not sequence dependent but perhaps number of samples or expts.
---------------------------------------------------------------------------------------------
I doubt I have anything useful for you, but we started having FIFO underflow
problems after we installed the Cold-Probe on our 600, which required that
we use dsp='i' and qcomp='y'. We didn't upgrade to VJ-2.1B, so I don't know
if this is still relevant at all to you.

We found that the frequency of the FIFO underflow was related to the value
of "oversamp". Basically, with in-line DSP, the entire oversampled FID is
sent to the Sun for filtering and downsampling. By decreasing "oversamp" to
a smaller value (i.e. 8), qcomp still works and the error has almost been
eliminated.

I arrived at the diagnosis by systematically doing simple 1D acquisitions
with a lot of oversampled points (large "sw", short "at"), and I
systematically decreased d1 until I started getting FIFO Underflow. If the
system is ready for the next acquisition before the ADC as transferred the
FID to the Sun, you get this error.

Of course, there are a lot of other reasons (usually the ADC board or the
DAC board), but I share the frustration that intermittent errors like this
can be a HUGE headache. They always seem to happen during an extended
multi-D experiment, when the instrument is unattended.
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

Cheers
-Kirk

Kirk Marat, Ph. D., NMR Facility Manager
Dept. of Chemistry
University of Manitoba
Winnipeg, MB, R3T 2N2, CANADA

C#, What C++ should have been
ph. (204) 474-6259 FAX: (204) 474-7608
kirk_marat_at_umanitoba.ca

ALL SPAM forwarded to Spam Cop
Received on Fri Sep 28 2007 - 10:38:55 MST

This archive was generated by hypermail 2.4.0 : Sun Jun 11 2023 - 16:37:45 MST