following Mark's message on friday, I'd like to comment point by point the
issues raised by Mark.
1-
>The cryogenic target
>monitoring will not be needed until February, is being developed by
>our collaborators at Saclay and so far they have only requested an
>RS232 port from us. I am taking this as a good sign, and will not
>mention this effort again in this note.
one point : HAS BEEN developed by collaborators at Saclay and HAS been tested.
I have personnally developped the EPICS interface that I have presented at the
last collaboration meeting. For what is in concern with EPICS it will be
installed in the EPICS hall B repository when the target will be installed.
II. Requirements for the December run
A. HV
>The low-level software we are using was written by Thierry Auger and
>Marc Swynghedauw under the supervision of Dave Barker. The main
>documents for their work are their master's theses, Refs. 2 and 3.
>Prominent features of the system are a new HV EPICS record with
>multiple VAL fields to accommodate the multiple constants associated
>with each HV channel, and a set of asynchronous tasks that form an
>interface between record support and the arcnet driver software.
precision: not only the low-level : Marc wrote also a GUI for HV which
worked quite well with one mainframe. I have made a demonstration on November
1995 which showed in action the GUI for one mainframe+the low-level software for
5 mainframes. Problems where encountered when using the GUI with more than one.
------------------------------------------------
>o Download of hardware constants
>Presently, if one tries download all of the system constants by
>repeated calls to channel access, the database will not update some
>key values, most notably the measured voltage of a channel. Also error
>messages appear on the IOC console. This probably has to do with the
>fact that the software does not wait for a response from a mainframe
>(the mainframe responds to every command) before going on to issuing
>the next command. Some element of data is getting lost or the desired
>logical execution thread is getting broken in a flood of channel
>access requests.
The measured voltage are not to be changed by channel access. This is an
information coming exclusively from the hardware. Therefore when you change it
to a different value, the EPICS software (depending on the scanning rate, here
it is periodic 5 or 10 seconds), will fortunately overwrite it to its real
value.
The software does not wait for a response:
_ For the monitoring part(99% of the time)it does, a look at the code
can prove it.
_ For channel access change, it doesn't. The ARCNET communication scheme
is that transmission is allowed if BOTH part are ready. This means that if the
driver transmits a message therefore the mainframe was ready to receive it. This
makes the flow of data, much smaller, which I have been able to see directly
with a VME bus scanner. Rather, is the size of the different pipes used in the
process large enough? these are the kind of question to raise before questioning
the driver.
One more note on that, LeCroy recently admitted that their driver had a
bug with an unforseen transmission case("Lecroy report on HV" e-mail, april 17).
From there comes their suggestion to slow down the rate of transmission
as a work around that bug. As far as I know they also solved the problem and
updated the mainframe's software, allowing operation without change to hall B
software.
> IV. Longer-range goals
-------------------------------------------
> A. HV
>
>o A new approach?
>
>The present HV software is not very well understood by Hall B
>personnel. As such, we will have difficulty maintaining it. One
>solution is to go to an entirely new, simpler scheme. If the approach
>chosen is the one Bonnie Madre is using for LeCroy 1454 control, then
>our Accelerator Division colleagues could maintain the code for us.
>
>Issues involved in this decision are:
> - Memory limits
> - Complications due to large channel count
> - Need for arcnet driver code
>
We (D.Barker and I) looked at the control code for LeCroy 1454. We decided that
in regards with our control problems, another scheme was needed. The choice of
developping a new record for hall B has been made during a meeting involving
every interested part somewhere around april 95 (B.Mecking, D.Barker, E.Smith,
G.Heyes, etc...). Memory limits was one of the issue at that time and it was
decided after having presented different schemes(e.g. one record by channel, one
record by card) that the HV channel record was the best compromise between
memory size, sizability, complexity of the software, flexibility and time needed
to develop it. At that time was made the choice to have configuration files from
where every tools(database building, GUI, low-level soft) could configure
themselves. The memory size wasn't considered as an issue ("Memory is cheap")
It took one year and a half of manpower to write it and it had to have some
changes afterword. Since developping is time-consuming I suggest rather to use
existing software with maybe some additions.
The HV configuration is going to be quite complicated anyway because of the
large number of channels and if one wants to use EPICS for HV control, there is
no simple way of doing it.
Is the driver not working?
---------------------------------------
>
> Why does initialization take so long? Is it really necessary to verify
>that the files conform to the hardware? Is it even desirable?
one minute by mainfraine is not so slow. Initialisation makes three things:
_ initialise ARCNET board. not more than 1 second needed.
_ Check that the database is in concordance with the hardware. It is
highly desirable at the beggining when setting up the configuration.
_ Read out all informations contained in the mainframe relevant to EPICS
operation and/or operator(Ramp up settings, limits, etc...).
>Should we change the software architecture to conform to the
>call-and-response mode that was intended by the LeCroy engineers?
It's possible and difficult with several mainframes controlled by one IOC.
And I don't see why it is needed. It will be much slower also.
>How does the system behave with multiple mainframes. Got two to work
>once. Can we do it again?
I made it working with 5 with an IOC of 8Mbytes of memory. There were just a
memory limitation which should not exist with the 16 Mbytes vme intended to be
used.
> Card-by-card rather than channel-by-channel initialization routine
>needed. Thierry gave us a skeleton program to start with here. Speeds
>up a download by an order of magnitude.
It is already the case for the checking parts of the initialization. For the
rest, it needs only 1 command by channel. To speed it up, would require the use
of the DUMP command which is not easy to handle in a networked environment.
> The mainframes have a built-in memory with battery backup. The values
>have been seen to survive unplugging and transport across the lab
>site. Can we exploit this feature to avoid time-consuming
>initialization procedure? For example, DUMP the values and onlydownload those
that need to be changed.
We (D.Barker, M.Swynghedauw & I) decided to rely on Unix stored files rather
than battery backup. The batteries are given one or two year time-life. What if
one forgets about it?
>We need an understanding of the following arcnet details:
> - How are interrupts used/handled?
> - Is the double buffering in the interface cards being exploited?
> - Are we generating reconfiguration interrupts? If so are they
> necessary?
interrupts are handled with an interrupt handler routine which is connected to
the interrupt by the VxWorks routine "intConnect()". It uses the double
buffering scheme althought this is not mandatory. It doesn't use the 16 bits
transfer mode but the 8 bits. For the synchronization see the ref[2] of Mark's
e-mail. Reconfiguration Interrupts are generated by the ARCNET board while
resetting or when a node quits or arrives in the network. The fact that you see
it at the initialization is normal and proves that the interrupt scheme works
indeed. The occurence of That interrupt could be a hint that a mainframe has
been disconnected from the network and could be used as a pre-diagnosis for
troubleshooting. Actually all it does is to print the message:
interrupt: int_handler() : Reconfiguration interrupt!!
It can also be disabled if needed. But it doesn't kill you to have it.
>All of the alarm fields in the HV record come to life as invalid. Is
>this good? Bad?
>
in July, I solved that problem in hall b directory but didn't checked in the
new code. If it is still occuring therefore the good files are not used.
Kathy worked with me on that.
> There will be an effort to use a LeCroy 1440 in the radiative phi
>decay experiment which sits in the alcove in Hall B. Dave Barker wrote
>a tcl-based gui which controls the same low-level routines that are
>resident in our library. Where is this thing? Does it work?
The GUI was written by Marc Swinghedauw and was used by the cosmic ray test crew
for the calorimeter. It is still available from them I guess.
>Do we need a system to remotely reboot the IOC's independent of the
>state of the IOC or the network? A mechanical system? What does ACC do
>about this?
P.Bonneau bought vme crates that allow remote monitoring of their status as well
as remote reboot. It needs a GPIB interface to be controlled. The plan was to
control the GPIB via an IP pack on a vme 162. The driver was available from the
accelerator. Peter must know about that.
Best regards,
Thierry.