Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Wed, 16 Nov 2005 15:01:16 -0500

On Nov 16, 2005, at 14:31 , Emmanuel Mayssat wrote:
I am actually doing something quite similar, but I am using a standard

camera with a frame grabber.

The issue I am facing is related to synchronization and data
processing.
For example I calculate the x and y profiles of a electron beam.
But while I can acquire image at 30Hz, epics can only process the
information at a maximum rate of 10Hz.
Is there a work around?
Is it possible to do real time video with epics?

Well, define "epics can only process .. at a maximum rate of 10Hz".
Yes, per default, the EPICS record scan rates (periods) include
"10 second, 5 second, .... 0.1 second",
which gives a max. of 10Hz.
But under vxWorks, especially after increasing the vxWorks 'tick'
clock rate, one can usually simply change the menuScan.dbd file
and add e.g. ".05 second" and voila:
"epics can ... process .. at a maximum rate of 20Hz".
But what you probably really want is:
Process in response to whatever triggers your camera to take
a picture.
Just like ADC driver/device support can be written to process
records on "I/O Intr" whenever the ADC receives a trigger,
you can write your frame grabber support to trigger record
processing whenever the frame grabber gets a new image.
The IOC application developer guide has details on the
"I/O Intr" mechanism. The EPICS "Event" mechanism might also
work.
For example, the SNS LLRF driver/device support can trigger
certain records to process on each RF pulse, which could
be up to 60 Hz.
So  "epics can ... process .. at a maximum rate of 60Hz".
I think there are examples out there in the EPICS community
of much higher rates.
The next problem:
When records process at a high rate _and_ there are
channel access clients which subscribed to updates from those
records, every time the records process, data is sent to those
clients (ignoring some ADEL/MDEL details).
In the case of the SNS LLRF, those records include waveforms.
All is OK as long as only one set of EDM screens is displaying
those waveforms. In practice, however, many screens are open.
Even though nobody is necessarily looking at the waveforms in all
of them, they all receive data from the IOC,
because the current Channel Access network protocol doesn't allow
client-specific update rates.
That's putting too much load on the IOC and network, and thus
the overall update rate suffers.
So the waveform update rate of the SNS LLRF was throttled to 2Hz,
using a 2Hz signal from the timing system, so gets updates from
all of the linac at exactly the same time, which appeared to be
more useful than more or less random update rates.
So one could say
"with many waveforms served by MVME2100 CPUs,
 monitored by many network clients,
 epics can ... publish data .. at a maximum rate of 2Hz".
I would assume that even if you only have an MVME2100 CPU,
you should be able to serve 640x400-sized images at 30Hz
to one or two network clients.
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System