Thank's to all who had responded to my earlier inquiry, below. Most of you suspected DSP interaction, and while I forgot to mention it in my original post, I had already checked to see if DSP='n', recalling this being an issue in NP errors of yesteryear. But today I did fire the ol' console up, and initially everything did work and seem to be in order. Went out to lunch with the sample locked, and came back a couple hours later and the lock was off and sure enough, no acqi lock signal again. Unfortunately at this point I had forgotten to try a "go" command, but instead turned off the card cage and removed the ADC board and physically removed the DSP mezzanine as 2 or 3 of you suggested. Upon booting the card cage back up, still no lock, however NO NP errors! I could 2H grad shim and acquire, albeit unlocked, but seems like now I have only 1/2 the problem as before....so that's progress! Interestingly, over the last few weeks the absent lock line and NP errors seem to go hand in hand (coincidence you say?), but now they appear to be isolated from one another. But at least now my focus will be back at the lock xtm/rcr and what generates that lock signal line on the digital side.
Thanks again, and if you have any further insight......
Neal
Neal J Stolowich, PhD
NMR Facilities Manager
Department of Chemistry
University of Louisville
Louisville, KY 40292
(502) 852-7894
-------------------------------------------------------------
>>> Neal J Stolowich 05/18/09 4:46 PM >>>
Greetings ammrlers,
For the last 6 weeks I have been battling the infamous "acquired points is not equal to np" error upon the start of an acquisition. In the past, usually an acquisition processor reboot is all that is needed, or some other minor fiddling, but not this time. Concomitant with this error also is the complete lost of the lock signal (not just zero lock, but the acqi lock display is all black - no lock line). I've swapped digital boards with my other 500, with an temporary fix, but only 30 - 60 minutes worth, so I don't really think the swapped board actually "fixed" anything. (Indeed, it turns out initially this problem seemed to be heat related, ie, it was the console being turned off for the board swap and ensuing cool down that resulted in the system working again, and not the boards actually being swapped)
So I was able to manage the room's temperature a bit better, had fans blowing on the console with the doors off and subsequently had a run of about 3 weeks with no problems. However the problem returned again, and for a few days an overnight shutdown would restore function for awhile the next day, but now this is no longer the case (probably whatever component that was acting up upon warming up no longer works now) But DC voltages still seem okay; a little more over range (~ 0.3V) then my other console on the front end of the power supply, but right at 5.04V at the back of the card cage for instance.
Considering the lock channel as well, back plane voltages looked okay, the RF signal output seems okay, and in any event with testing on the other working system, removal of any of the outputs results in flat lining the lock signal - not complete loss of it. So its not likely the problem. I'm at loss of where to go next, except for maybe a service call of course.
Oh yes, one more tidbit of info: acqdebug(11) with tip hardwire does result in the following error message:
[IntContxt]:'stm0bj.c' line:198, Error Intrp RPNZ/MAX (Vec:0xb0), status: 0x22, tag:0
[IntContxt]:'stm0bj.c' line:208, STMRPNZ_DATA_ERROR (Vec:0xb0), status: 0x22, tag:0, NP Remaining cnt=256
Can you think of anything else that I or Varian might be missing?
Thanks,
Neal
Neal J Stolowich, PhD
NMR Facilities Manager
Department of Chemistry
University of Louisville
Louisville, KY 40292
(502) 852-7894
-------------------------------------------------------------
Received on Fri May 22 2009 - 10:00:06 MST