Experimental Physics and
Industrial Control System

"Ru Igarashi" <[email protected]> · Tue, 6 Oct 2009 13:13:35 -0600

Folks,
Sorry for taking so long to get back to the ML on this
subject.  It's just taken this long for the resolution.

Thanks to a script that Mark River's sent, we were
able to determine that the problem either lay in WinView
or the hardware.  The firewire cable or the card in the
PC did not seem to be the problem (though it could have
been the PC in general) as we swapped various components
to no avail.  Upgrading Winview (and using WinX) did
not help.  Ultimately, the engineers at Princeton
Instruments surmised that there was a problem in the
firmware and did a remote firmware upgrade.  That solved
the problem.  There was a peripherally related issue in
the duration of acquisitions that revealed that the
camera was previously not running its cleaning cycle at
the start even though it was set to.  That threw us for
a while until the engineers clarified what the proper
timings were, and that the camera must not have been
cleaning appropriately before the upgrade. We have run
unstalled (using areaDetector) in the two weeks since
(many tens of thousands of images).

ru

Ru Igarashi wrote:
> One of the beamlines at the Canadian Light Source (CLS)
> uses a Princeton Instruments (Roper) Quad-RO CCD detector
> (2084x2084). We have used the synApps 'ccd' application
> in the past, and have recently attempted to use the
> 'areaDetector' app instead.  In both cases, however,
> when we run multiple image sequential scans, the hardware
> locks up.  We essentially run a loop triggering the
> detector via the ccd/areaDetector's acquire PV, wait
> for a monitor from the acquire status, make sure the
> status is "Done", do a few other tasks, then trigger
> again.  There's at least 1.5 seconds between the end
> of the trigger "Done" change-of-state and the subsequent
> software trigger. The sequence is typically set for
> 2500-4000 exposures.
> 
> With 'ccd' we could get about 2500-3000 exposures before
> the hardware locked up.  At least we think it is the
> hardware because WinView still operates (e.g. close image,
> start acquire, empty image frame appears, but no image),
> restarting WinView does not solve the problem, and only
> a hardware power cycle (long wait) solves the problem.
> With 'ccd', there was a proxy app that displayed comm
> traffic, and at the onset of the problem, it was clear
> that communications were out of sync (command acks too
> early, missing data packets) and remained out of sync.
> 
> We were hoping a switch to 'areaDetector' would resolve
> this issue but it seems to have actually made the situation
> worse: we now only get at most a few hundred exposures
> before locking up.  Adding more time between exposures
> (in case there was some sort of interference with
> communication before or after an exposure) did not help,
> either.
> 
> It looks as though areaDetector holds the status flag
> "busy" until after the data is written to file, and we
> don't think we see an overlap with disk or network activity
> (haven't thought through caching issues properly), so it
> doesn't seem to be a problem with triggering during the
> previous image's file I/O.
> 
> The CCD hardware is linked to a Windows XP box via firewire.
> XP is Service Pack 3 (so it isn't the old SP 2 bug).
> areaDetector is V1.4 (prebuilt), ccd was V1.6.  WinView
> is V2.5.22.0.
> 
> Has anyone else experienced the same kind of problem
> with their Roper CCD detector?  What can we do to either
> further diagnose the problem or resolve it?  Perhaps
> a Windows app that that can replace and perform the same
> scan operations a few thousand times?

-- 
Ru Igarashi                   Software & Instrumentation Specialist
e-mail: [email protected]  Canadian Light Source
ph: 306 657 3751              University of Saskatchewan
fax: 306 657 3535             Saskatoon SK S7N 0X4

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System