ISOGEOCHEM Archives

Stable Isotope Geochemistry

ISOGEOCHEM@LIST.UVM.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ethan Goddard <[log in to unmask]>
Reply To:
Stable Isotope Geochemistry <[log in to unmask]>
Date:
Mon, 8 May 2006 11:51:38 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (136 lines)
I agree with Wolfram that Brian Jones is right on the mark in regard  
to RAM and Isodat.  I am now up to 2MB RAM on a sys running Isodat  
2.0 and a Kiel-III and I finally seem to have licked frequent and  
quite ambiguous application crashes.  The CF-IRMS Isodat sys that we  
run gets by on much less RAM - 512K seems to do the trick.

just my $0.02

cheers,
Ethan



末末末末末末末末末末末末末末末末末末末末末
Ethan A. Goddard - USF College of Marine Science
140 7th Ave. S    St. Petersburg, FL 33701
727-553-1017(lab);  -1016 (office);  -1189(fax)
[log in to unmask]
http://marine.usf.edu/PPBlaboratory
末末末末末末末末末末末末末末末末末末末末末





>
>
> From: Dr W Meier-Augenstein <[log in to unmask]>
> Date: May 5, 2006 2:10:10 AM EDT
> Subject: Re: Isodat problems
>
>
> Hi Brian,
>
>
> I think you hit bull's eye with your conclusion that this might be  
> 'simply'
> a resource problem though I am not sure why this should physically  
> corrupt
> calibration and configuration files.
>
> However, as mentioned in my prior posting, I have seen the system  
> crashing
> at the same seemingly critical point (end of peak and about to  
> jump) without
> a  lost magnet position being the reason, and I was always  
> wondering if
> Isodat was getting its knickers in a twist because it was trying to  
> do too
> many handshakes or trying to keep tabs on too many processes at any  
> one time
> within itself.
>
> Eliminating access-to-CPU-time-, IRQ- or hex addressing conflicts  
> by running
> nothing but Isodat is quite easy, but for Isodat to trip itself up  
> even when
> only that's running is the Acquisition module is quite another matter.
>
> Makes one wonder why Thermo ship their systems with PCs that ain't  
> fit for
> purpose, i.e. are under-resourced (apart from the obvious cost-cutting
> reason). Still, to save a few hundred quid on systems that usually  
> come in
> around the 100k mark doesn't make sense; especially when they tell  
> you if
> you decide to use a different PC other than that supplied you do so  
> at your
> own risk.
>
> The PC that came with our Delta_plus_XP has only 256MB of RAM.  
> Based on your
> experience, I think I will treat myself to a memory upgrade.
>
>
> Thanks for sharing your experience.
>
>
> Wolfram
>
>
>
>> -----Original Message-----
>> From: Stable Isotope Geochemistry
>> [mailto:[log in to unmask]] On Behalf Of Brian Jones
>> Sent: 04 May 2006 18:30
>> To: [log in to unmask]
>> Subject: Re: Isodat problems
>>
>>
>> Hi Les,
>> I too had this same or similar problem for a while. The error
>> message I got was 'program: C:\finnigan\isodat
>> nt\global\bin\workspace.exe - abnormal program termination -
>> (press retry to debug program)'. This error window coincided
>> with a lack of jump from N2 to CO2 configuration. If I
>> clicked any of the buttons the acquisition screen terminated.
>> If I left the screen alone the sample schedule would
>> continue, but could receive the same error again and open a
>> new error window.
>> I too attempted reloads of Isodat, recalibrated the mass
>> scale, deleted and recreated jump files, erased the entire
>> computers hard drive and started over, and removed and
>> replaced memory (as I always received a memory error after I
>> closed the error message mentioned above). None of this
>> solved the problem. I was able to narrow down the fact that
>> the jump file was becoming corrupt for some reason after
>> creation. Deleting and recreating this file would solve the
>> problem for a time, but would always reoccur, however, not in
>> a predictable number of jumps or other factors I looked at.
>> Eventually, I replaced the computer with another that has
>> dual processors (don't think this matters) and 1GB of RAM
>> memory (I do think this matters). I have not seen this error
>> message again. I am not certain that the increase in memory
>> was the solution; perhaps the old computer had another
>> problem within the motherboard or memory cards themselves.
>> However, when I tried to reproduce this error on the new
>> computer by loading the memory and processors with open
>> programs while acquiring data I did receive an error message,
>> however it was different, go figure (sorry did not write it
>> down). This time the jump file was fine and did not get
>> corrupted and once the memory was freed up again the error
>> messages stopped. At any rate, I have not seen this error or
>> had trouble jumping since the change in computer. I have had
>> runs totaling 150 samples and have probably run in excess of
>> 5000 samples so far without problem. I can dual task using
>> internet, email, word and excel without having a problem. I
>> realize this is not really a certified solution, but may be
>> something to look at. If you are able to borrow a high memory
>> system to test, it might save you the expense of buying a
>> system that is not the solution. I any case hope this helps.
>> If you discover the real problem I would be very interested
>> in your findings Brian Jones Stable Isotope Ecology Lab Texas
>> A&M University College Station, Tx. 77843-3146 979-845-8916
>>

ATOM RSS1 RSS2