Experimental Physics and
Industrial Control System

tieman <[email protected]> · Thu, 06 Mar 2008 22:42:18 -0600

Mark,
I've had thoughts of redesigning my Image Server for several years now.
The software is actually capable of handling most of the disadvantages
you list, however, it fails miserably in many other areas :( The
biggest disadvantage is certainly the reliance on a windows only widget
toolkit but there are a growing number of limitations centered on the
growing use of machine vision type cameras and very high frame rates.
I've thought about the standard EPICS IOC route. The Image Server was
always an application first and a PV server second. I still believe
there is value in that philosophy but can see the value in going
standard EPICS. 
I don't see a danger in sticking with the Portable Channel Access
Server. There's enough code reliant on it now that I don't see it going
away. It does not suffer from the 16K barrier if built to avoid it but
I generally disagree with EPICS as a means to move image data. I've
already done a small amount of preliminary work in developing a new code
base using the PCAS but it's nothing that can't be thrown away.
An interesting option would be the JavaIOC. My real fear there is
longevity. If something happens to Marty (and I certainly hope nothing
every does!) and no other facility picks it up, then the JavaIOC dies or
you become daddy. Neither is appealing to me. Still, it is a tempting
option and if I had time to play I might give it a try.
The rough design I was thinking about is
1) A core acquisition driver that is common for all detectors.

2) Camera drivers for each camera type. This would be very similar to
the driver already in the Image Server but better abstracted from the
core code than the Image Server manages. This would be the only code
one would need to write to add a new detector. This part has worked
very well in the Image Server and does wrapper vendor interfaces
well--including vendor GUIs.

3) ROI drivers for various ROI types. This would actually be a list of
drivers to support multiple ROIs. Different ROIs would be capable of
different calculations, may be different shapes (some people use
calculations of the ROI as point detectors at times), etc...

4) Communication drivers for communicating with the outside world.
These would include EPICS and various file formats and others oddities.
This would also be a list of drivers--mostly so data could be forked to
multiple locations (a local USB drive for archival and also to a remote
processing cluster for real time analysis, etc) There would be two main
types of communication drivers: synchronous and asynchronous.
Synchronous drivers would handshake with the acquisition driver to
ensure data integrity. Asynchronous drivers would be allowed to drop
data to allow the acquisition loop to run full tilt.
The core acquisition driver, camera and ROI drivers would register with
the communication driver to provide access to the application. The GUI
would be fully decoupled allowing the application to run cross platform
and the GUI to be determined by the user. A "standard" GUI would be
developed. I thought about ImageJ. I've written several plugins for
ImageJ and there are loads of plugins available to do just about
anything. It's really not the best platform for anything performance
oriented (it might be difficult to use to focus the detector, for
instance) but a lot features are already there.
Another key feature is that each driver would be allowed to register
it's own set of fields with the communication drivers. This means each
instance might have a different set of supported PVs. This has become a
big issue with the Image Server and one of the motivations for a
rewrite. The Image Server started with the "one set of PVs fits all"
approach and its failed. To continue to maintain a full set of PVs for
every camera even if they aren't used is trouoblesome and confusing to
the user. The core PVs can be the same for all cameras, but does every
camera need to support "Pixel Clock", "Black balance", "Frame Rate" and
"White Balance". It hasn't been too combersome to provide a "camera
type" PV and let the control script sort it out. The differences are
almost universally in the configuration stage.
In addition to the detectors Mark lists, a new solution would need to
support:
1) Cooke SensiCam

2) Sarnoff Camera

3) Detector Pool developed systems (Gold, Mercury)

4) Coreco Frame Grabber--this is a bit more complicated. The frame
grabber uses a standard API for all cameras (LVDS and CameraLink mostly)
but only provides an RS-232 connection for camera control. Each camera
implements it's own configuration control via firmware (camera commands
are rarely ever the same--even from the same manufacturer)

5) uEye USB Camera

6) Apogee cameras

7) Fairchild camera

8) And I've found it very useful to have a software generated test pattern
The Image Server also supports a few additional cameras, but I am not
aware these systems are still in use and likely this support can be dropped.
9) MicroImager from QSystems--now owned by Pi/Acton (Roper)
10) Andor Technologies
11) Epix frame grabber
12) Twain (already dropped)
Plus I am aware of 2-3 potential new detector systems not covered by the
above that users are considering purchasing within the next year.
I haven't walked too far down this road yet (a hesitant step or two)
because I don't think it should be my decision. I've raised the issue
several times (Mark and some others may remember a meeting a few years
ago where Mark, Steve Shoaf and I each presented our approaches to area
detectors) but things have been stable and thus no reason to do anything
different. I agree with Mark that it would be nice to have a single
solution for areas detectors and the community should speak up for what
they need.
Brian

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System