Just got this from Mike Green of LeCroy. Posting it here for your
information and comment.
-- Mark
------------------------------------
Hi Mark,
While I readily admit that the most recent ARCNET problem (LAC as
referred to in an earlier message) is a bug in the 1458 mainframe firmware;
I feel it needs to be pointed out that the operation of the CEBAF VME-ARCNET
driver has an undesirable feature which needs to be addressed.
During our most recent debugging session, I installed an
intermediate version of HV mainframe firmware which had a bug in the
handling of the RM command (Recall software limits) for the Channel Enable
property. This caused the mainframe to issue an error message when this
command was received. I noticed that the error message was ignored and the
control system continued sending commands.
Ignoring error messages is a not good idea. Indeed, when a software
limit for a target voltage has been set, any attempt by a user to load a
target voltage higher than this limit results in an error message response.
One could imagine that, due to the slow monitoring rate, a user could
(unknowingly) set some voltages greater than the their limit then
immediately turn HVON. The possibly undesirable effect could occur where
some channels would ramp up to their target voltage and some would not
(namely, those whose settings exceeded their software limit and thus were
left at their original target voltage -- possibly zero). This might be OK
for supplies used in phototube applications but could have more severe
consequences for supplies used for wire chambers.
This can be avoided if the VME-ARCNET driver is changed to only
place a single command into the VME-ARCNET interface hardware at a time for
a given HV mainframe. The driver should wait for a response to this command
and check that the word "ERROR" is not contained in the response message.
(For multiple-line responses, the first byte of a response message always
contains a 'C' if another line is to follow. In which case, the driver
should wait for a complete response; that is, a response message without a
'C' in it's first byte.)
Of course, a message to another HV mainframe on the same network (at
a different ARCNET address) could be loaded into the ARCNET interface
hardware at same time, one should just avoid having two pending messages for
a given mainframe. In the operation of multiple mainframes, the driver
should have a separate queue of messages for each mainframe from which it
would load the ARCNET interface HW with restriction of only one active
command per HV mainframe; thus allowing HV mainframes to process commands in
parallel.
It is possible that the current driver is written such that when
more than one mainframe is being controlled, multiple messages going to the
same mainframe can block the VME-ARCNET hardware which is waiting for ARCNET
buffers on a receiving mainframe that is processing a previous message. This
condition would prevent messages from being sent to available ARCNET buffers
on another mainframe resulting in slower operation for the entire HV control
system.
The irony here is that if the current VME-ARCNET driver would have
been written so as to allow only one active command (per mainframe) at a
time, we would have never seen the LAC problem. The LAC problem would then
have only shown up for situations where 2 hosts are talking to the same
mainframe (for controlling possibly separate groups of modules in the same
mainframe).
In summary, we consider the LAC problem to be a mainframe bug. (A
fix has been implemented and soon will be installed on all CEBAF HV
mainframes). Nevertheless, it would seem to be good practice to NOT ignore
error messages, and in fact disallow (ignore?) at least certain commands
(HVON, LD, LM and possibly any other command which changes mainframe
settings) after an response contains an error until some user intervention
has occurred (like resetting an error status "alarm"). This necessarily
requires that the driver check the response message for every command before
sending another command to the same mainframe. Also, for multiple mainframe
control, only sending one command at time to a given mainframe allows the
ARCNET-VME hardware to "deal out" a series of commands to multiple
mainframes which then process their commands in parallel with no ARCNET
buffer blocking.
Mike Green
Mike_G@pisun.lecroy.com
LRS Engineering
LeCroy Corporation (LCRY)