<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Richard,<br>
<br>
In general we try to avoid placing computers in Hall D and the
Tagger Hall unless absolutely necessary (e.g. front-end ROC's), for
a number of reasons including the expense of the extra computer,
the overhead for managing it in the radiation controlled areas and
long-term maintenance.<br>
<br>
I had a long talk with our network experts and fortunately I don't
think this will be necessary. If you follow all the rules of the
Ethernet Transport Layer (layer 2) then our network equipment can
transport your packets to (Linux) computers in the counting house
(and v.v). The key is that our folks can arrange for your device
to be on the same VLAN as the computer in the counting house. This
is not necessarily the same as being on the same subnet, an IP
concept that is not applicable to the Ethernet Transport Layer, but
in our case it is functionally the same. Note that our network gear
will transport MAC broadcasts as well, so I think all bases are
covered.<br>
<br>
In general it would be preferable for your device to communicate via
the IP layer, so if you can do that then all problems disappear.
But if that is not possible we will not require a special computer
(e.g. PC104) in the Tagger Hall.<br>
<br>
If you are unsure whether you are satisfying all the rules of the
Ethernet Transport Layer contact one of our network experts (Bryan
Hess, <a class="moz-txt-link-abbreviated" href="mailto:bhess@jlab.org">bhess@jlab.org</a>).<br>
<br>
Please get back to me if you don't think the strategy above will
work for some reason.<br>
<br>
Thanks,<br>
<br>
<br>
<br>
On 04/03/2012 11:16 AM, Richard Jones wrote:
<blockquote cite="mid:4F7B1461.4030203@uconn.edu" type="cite">Hovanes,
<br>
<br>
That sounds good. Since you already have an idea of the
functionality that this API should expose, let me ask you for a
favor. Can you draft an interface specification for the C or C++
API that we should implement on top of our protocol? Things that
we would not think of, for example, would be to ramp the bias
voltages up and down gradually. At these low bias voltages, our
instinct would be to just switch them on and off abruptly. But if
operators are not used to that, it might cause concern or
confusion. Having as uniform as possible an interface to all
operating voltages on detectors would seem to make sense, and you
might be better able to design that than I would.
<br>
<br>
If you write the API specification, I will provide a tested
library layered on top of pcap that implements the API.
<br>
<br>
-Richard J.
<br>
<br>
<br>
<br>
On 4/3/2012 7:47 AM, Hovane Egiyan wrote:
<br>
<blockquote type="cite">Hi Richard,
<br>
<br>
thanks for your quick response. It sounds like what will be
required in hardware is a Linux computer and a network hub. We
do plan to have a VME crate with a Linux controller in the
tagger hall. But if we do not want to tie this application to a
VME crate then we could instead just attach together an
embedded PC running Linux EPICS Input/Outut Controller (IOC)
process and a network hub (or make a small chassis) that can be
mounted in a rack.
<br>
<br>
For the software side, it would be nice if we had a C or C++
library above pcap that would provide a set of functions to read
and write parameters into the control boards. That would
facilitate interfacing the voltage control with EPICS. We would
need to discuss the parameters and the set of functions in
details.
<br>
<br>
Hovanes.
<br>
<br>
<br>
On 4/2/2012 7:17 PM, Richard Jones wrote:
<br>
<blockquote type="cite">Hovanes,
<br>
<br>
These microscope readout control boards communicate with a
host over a private ethernet segment. The physical layer is
just RJ45 twisted
<br>
pair ethernet, using a cheap 10Mb hub. The ethernet protocol
can coexist with normal ip traffic without interference on
this segment,
<br>
but it only uses the ethernet transport layer so it requires
the host to be on the local segment. The protocol does employ
special
<br>
broadcast packets for automatic discovery and global reset
functions. It is our own protocol.
<br>
<br>
I think the best way to control it in the hall would be an
epics application that runs on an in-crate computer with one
of its ethernet
<br>
ports dedicated to the private segment. Thank you for
starting us thinking about this. Right now our software runs
on a windows app
<br>
built on the pcap library, but there is not a lot of
investment in that. We just set that up because it was quick
and did not require us
<br>
to buy a VME crate.
<br>
<br>
-Richard J.
<br>
<br>
<br>
On 4/2/2012 3:56 PM, Hovanes Egiyan wrote:
<br>
<blockquote type="cite">Hi Richard,
<br>
<br>
We are planning the controls for voltages for Hall D. Tagger
microscope will be using SiPMs for which UConn is providing
the bias voltages
<br>
and the power to the boards. At this stage we would like to
know how these are in principle designed to interface with
EPICS. Is this going to be a standalone Labview program
which will have to be interfaced with EPICS, or you could
provide a library that could be used to integrate it with
EPICS on Linux, or you are using some standard communication
protocol we could use to talk to these boards. Also I would
like to know which parameters will be controlled and
monitored. I listed below what (hopefully) will be available
to the software for voltages for other detector components.
<br>
<br>
o Voltage Setpoints (RW)
<br>
<br>
o Voltage Readback (R)
<br>
<br>
o Maximum Voltage (RW)
<br>
<br>
o Current Readback (R)
<br>
<br>
o Maximum current(s) [trip] (RW)
<br>
<br>
o Time for trip condition before turning off (RW)
<br>
<br>
o Channel Status
[On/Off/RampingUp/RampingDown/Tripped/etc] (R)
<br>
<br>
o Switch On/Off (W)
<br>
<br>
o Board Temperature (R)
<br>
<br>
<br>
Although it would be desirable if all detector components
have similar features exposed to the shift operators, this
list is obviously dependent on the features of the detector
and can change.
<br>
<br>
Also, when do you think we could have an opportunity to have
a system at JLab that will allow us to develop an EPICS
interface for these
<br>
voltages?
<br>
<br>
Thanks,
<br>
Hovanes
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Halld-tagger mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-tagger@jlab.org">Halld-tagger@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-tagger">https://mailman.jlab.org/mailman/listinfo/halld-tagger</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Sincerely,
Elliott
================================================================================
Those raised in a morally relative or neutral environment will hold
no truths to be self-evident.
Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365
================================================================================
</pre>
</body>
</html>