[RASMB] timing of auc runs

[John Philo]

Judith,

It is normal for the absorbance scan timing to vary from one scan to the
next. For any given cell the number of data points actually recorded varies
from one scan to the next so clearly the total time will also.

I'm not sure though why this run length variability presents a problem. If
you really want the timing to be consistent then you must set a delay
between scans that is slightly longer than the minimum time to scan all the
cells once. That's the trade-off: if you want the fastest scanning possible,
then the rate will vary; if you want consistent timing, you have to slow
things down a bit.

Regarding why the timing varies, certainly one reason is simply that the
rotor rotation, slit motion, and lamp charging are not synchronized. For
each lamp flash the data acquisition board (DAB) has to wait until the slit
is approximately at the desired radius and the lamp has re-charged and is
ready to fire again, and then the DAB must wait until the correct cell
rotates under the monochromator. The overall time for that sequence then
varies from one flash to the next. Another reason (and actually I think this
is probably the main one) is that the DAB computer also has many other tasks
to do (like communicating with the PC and the computer than runs the
centrifuge). At best it can barely keep up, so sometimes it is simply not
available at the soonest point another flash can be fired. Sometimes too it
will not immediately process the message from the PC to start the next set
of scans (all the cells once).

Another thing that can happen sometimes is that the DAB computer gets so
busy it starts running behind, and then the messages running back and forth
between it and the PC (through the serial cable) pile up. When this happens
you can actually see that the run time being displayed in the run monitor
window on the PC is running minutes behind the time shown on the centrifuge
CRT. A few times when I stopped a run the rotor had completely stopped but
the DAB was so far behind the PC said it was still going at 60K! This seems
to happen most often when you are running at high speed and when you do a
bunch of runs without ever turning off the power to the centrifuge.

John
-----Original Message-----
From: rasmb-bounces at rasmb.bbri.org [ <mailto:rasmb-bounces at rasmb.bbri.org>
mailto:rasmb-bounces at rasmb.bbri.org] On Behalf Of Judith Kornblatt
Sent: Friday, September 25, 2009 1:19 PM
To: smcbryan
Cc: rasmb at server1.bbri.org
Subject: Re: [RASMB] timing of auc runs

In reply to the same question from two of you, yes, the Rmin and Rmax are
the same in every run - we never change them.
Judith Kornblatt

smcbryan wrote:
> For your first two experiments at 32K, you are collecting data at
> 3.975 minutes per scan and 4.455 minutes per scan for the 13:15 and
> 14:51 experiments, respectively. Assuming you are scanning in the Abs
> mode (which the scans per unit time suggests) that is a significant
> difference between scan time, if you set the radial increment and scan
> limits (Rmin and Rmax) the same for both runs. Did you set Rmin and Rmax
to the same limits?
> Our machines won't collect every scan at the set radial increment,
> typically a 0.001cm experiment will average 1.0015cm radial
> increments. But that value is the same between different experiments,
> so your differences are unusual.
> Steve Mcbryant, PhD
> Director, PPC Facility
> Colorado State University
>
>
>
>
> On Fri, 25 Sep 2009 13:38:01 -0400, Judith Kornblatt
> <judithk at alcor.concordia.ca> wrote:
>  
>> How consistent should the length of time for a run be? I've been
>> doing the same basic run multiple times - same speed, same number of
>> scans - and the total time for the run, as displayed on the panel of
>> the AUC, varies considerably. For example, 200 scans, 32000 rpm, the
>> times varied from 13:15 to 14:51. More recently, 200 scans at 37000,
>> times varied from about 13 hours to 14 hours. Is this variation normal?
>> Judith Kornblatt
>> Chemistry and Biochemistry
>> Concordia University
>> Montreal Quebec
>>
>> _______________________________________________
>> RASMB mailing list
>> RASMB at rasmb.bbri.org
>>  <http://rasmb.bbri.org/mailman/listinfo/rasmb>
http://rasmb.bbri.org/mailman/listinfo/rasmb
>>    
>
>
>  


_______________________________________________
RASMB mailing list
RASMB at rasmb.bbri.org
 <http://rasmb.bbri.org/mailman/listinfo/rasmb>
http://rasmb.bbri.org/mailman/listinfo/rasmb


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.rasmb.org/pipermail/rasmb-rasmb.org/attachments/20090925/3df4aa69/attachment.htm>