Experimental Physics and
Industrial Control System

"Lawrence T. Hoff" <[email protected]> · Thu, 07 Sep 2006 11:35:36 -0400

Kay-Uwe Kasemir wrote:

On Sep 6, 2006, at 02:30 , Jon Brinkmann wrote:
Does StripTool2_5_10_0 display waveform records?

Hi:
It doesn't, and it couldn't.

	Well, as you point out, it *could*, but only
with additional information and sophisticated logic.
	I will tell a long-winded story, the upshot
of which is that I believe that a minimal extension
to StripTool, combined with the (complimentary) SNS
scope tool, could usefully address the vast majority
of waveform display applications....
	Of course, talk is cheap, and I am not actually
volunteering to do any real work. I am only offering to
share experience, and let others decide whether there
is something broadly palatable worth pursuing...

-- Larry

	We recently struggled with this issue at BNL,
primarily because we had a strong need to correlate
data from many sources within the complex (5 different
accelerators, with unique timing characteristics, and
non-accelerator data).
	The conclusion we arrived at is essentially
identical to what Kay described. We decided to attack
the problem as follows:
	1) For some systems, we created (the RHIC
equivalent of) a "time info" record, with fields
describing the characteristics of the waveform
(much as Kay describes). E.g. one field puts the
data into one of those categories Kay enumerates,
one field describes the time of the waveform "trigger",
another describes the position of the trigger within
the waveform (beginning, end, somewhere in the middle),
another provides the inter-sample timing, etc.
	We probably went overboard, including fields like
"signal bandwidth" (to describe a correlation window for
data with different collection characteristics), and
handling the case of multi-segment data (e.g. data
acquired on multiple, separate triggers, but reported in
a single waveform).
	We then made the RHIC equivalent of StripTool
(General Purpose Monitor) sensitive to this information,
so it could sensible display data from different sources.
	Obviously, populating, maintaining, and verifying
such records requires effort, so we only used this technique
for high-multiplicity, well-defined, and commonly used
data sources (e.g. ramping magnet power supplies, loss
monitors, etc.).
	Note also that one could use a relational
database or plain files to store the same information.
In any case, there needs to be some way of relating the
waveform record to the "time info" record (if it exists).
We chose the (unsophisticated) technique of using a
name extension (i.e. "time info" record name is the
record name with a ".timeInfo" extension). It works,
but I am sure there are better ways to make that association.
	2) General Purpose Monitor (GPM) also allows users
to *manually* define the salient time characteristics
of a signal when that signal is added to the display.
These configurations can be saved between invocations of GPM.
	This technique is best suited for highly dynamic,
ad-hoc situations. If the signal characteristics were more
stable, they should be addressed by technique #1.
	3) As a default, because *something* is better than
*nothing*, GPM was designed to display waveforms even in the
absence of any information describing the time characteristics
of the waveform. StripTool could easily be enhanced in a
similar way. GPM uses one of two techniques:
	A) If a new waveform arrives within some time threshold
of the previously published waveform, the data is presented with
each waveform element evenly distributed in time. This ends up
working well for us, because it is common for us to do things like
collect 720Hz magnet power supply data which is "published" at
1Hz. In that case, the data is displayed as it each waveform
element were separately published at 720Hz. GPM assumes that
the waveform timestamp applies to the first element.
	B) If waveforms arrive "infrequently", some default
inter-sample time is used, based on the length of the waveform.
I.e. if waveforms of length 10,000 come every 4.5 seconds,
GPM might decide that the inter-sampling rate is 10KHz,
but if the waveform were of length 100, it might assume 720Hz
(a common timebase at RHIC).
Obviously, these heuristics are far from fool-proof, and have
resulted in some peculiar displays (data "spread out" when it
should not be, or data "compressed" when it should not be).
Nevertheless, I have found it surprisingly useful, especially
if the alternative is no display at all. Even binary data
such as raw video can be meaningfully displayed with GPM!
HTH

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System