Hi, all,
This is a description of some problems with the high voltage software
that have surfaced in the last several months that have now been
solved. Mark Ito asked me to share this with the rest of the mailing
list.
These are listed in the order discovered.
In all cases epics baseB was used (base version for Hall B).
Problem #1:
Ioc clasgas ran all the software correctly, or at least there didn't
appear to be any problems. It addressed the LeCroy through Arcnet,
and the LeCroy mainframe responded correctly. Clasgas is a MVME167,
a 25 MHz clock speed target board. When the software was loaded
onto an MVME167-33 (a 33 MHz board), It would reach the point where
the initialization of the mainframe occurred, then spontaneously
reboot itself.
The problem here, apparently was an incorrectly referenced pointer,
because when Thierry Auger discovered it and fixed it, the ioc
stopped rebooting itself (thanks Thierry!). That allowed us to
run into the next brick wall.
Problem # 2:
Now that the ioc was not rebooting itself, the initialization was pro-
ceeding. Here's the error message that began to appear.
0xe830ec (1458_Async): analyse_reply() : unexpected message!!!
0xe830ec (1458_Async): analyse_reply() : 134 ERROR - #134 |Numeric Value Requ
ired|
task: 0Xe830ec 1458_Async
timeout problem!! the mainframe doesn't reply to any command
It turned out that there were two problems here. The first one - the
the error message - definitely caused the mainframe to time out, but
there was another problem, too. More on that later.
From Thierry, I discovered that there was a utility switch_print(), that
will show the commands that are being sent to the mainframe. (Thanks,
Thierry!). What I discovered was the following:
pbuffer=RM S1 CE
0xe830ec (1458_Async): analyse_reply() : unexpected message!!!
0xe830ec (1458_Async): analyse_reply() : 134 ERROR - #134 |Numeric Value Requ
ired|
There is *nothing* wrong with the command "RM S1 CE". It isn't particularly
useful, since CE is either 1 or 0 and the RM command is asking for software
limits, but the command gives no error message on the mainframe attached
to clasgas. I commented out the lines that send that command, and the
initialization proceeded without the above error message. Exactly how
many revisions of the LeCroy firmware do we have on site, and are there
any plans to update all of them to the same rev? On to the next obstacle....
Problem # 3:
I still got the following error message when the initialization was
complete:
task: 0Xe830ec 1458_Async
timeout problem!! the mainframe doesn't reply to any command
Now, thinking that the difference in clock speed had changed the timeout
requirements, driver code was examined. It was found by (you guessed
it!) Thierry, who noticed that a counter was not initialized in the
routine that spawned the sequencer task (necessary to keep tabs on what
the mainframe is doing). Since the counter was already at the maximum
permitted in the "for" loop, the sequence task was not getting spawned.
Once that was fixed, we were, in the vernacular "good to go". I
have returned clasgas to its rightful place (no, I was not really
holding it hostage until we got mine working - it just seemed that
way). Again, thanks Thierry! This counter had, in fact been re-
initialized in an earlier development version of the software, but that
apparently did not get checked into CVS. It is in CVS now.
The modules that have changed are devArcnet.c and seqArcnetDVL.c, and
the Makefile. At some point seqArcnetDVL.c will become seqArcnet.c,
but there will be a test period first.
Any questions, problems, comments or if you have a extra '58 Corvette
that you're giving away, call me.
--
Bonnie Madre
Staff Computer Scientist
Accelerator Controls Software Group
ANALOG ADDRESS:
Thomas Jefferson National Accelerator Facility (TJNAF)
MS 85A
12000 Jefferson Avenue
Newport News, VA 23606
(757) 269-7059
E-MAIL ADDRESS:
madre@jlab.org