Re: [BLAST_SHIFTS] Troubleshooting camac

From: Karen Dow (kdow@mit.edu)
Date: Thu Nov 07 2002 - 13:19:23 EST


        A few more points on diagnosing CAMAC problems:

1) The arguments to cnaf are the target (the ROC name where the
VME-to-CAMAC interface is located; blrocv1 in our case), the crate # (1
for beam right, 2 for beam left), the slot # in the crate, the address
in the slot, the function (0 to read, 16 to write), data (needed for
f16, not for f0).

2) cnaf can take a hex argument for the data to write (f=16):

> cnaf blrocv1 1 23 16 0 0xffffff (to get all bits set)

3) Crate 1, slot 23 is actually a dataway display (Kinetic Systems
3291), so in addition to showing you the data bits read/written, it also
has LEDs that show the last function (f) and address (a) for the crate.
If the branch highway cable is stressed and some pins are not making
contact, usually you will see this on the read/write data pins. Or the
function, slot or address will have an extra/missing bit, so the crate
won't see a valid command, and you won't get q=x=1. But sometimes the
non-data LEDs are the only way to see the problem.

        I believe you only want to use address 0 (data register) for this
module; address 1 is the control register.

4) The output register (Std Engineering PR-612) in crate 2, slot 22 has
two addresses, 0 and 1. Either will work for this test; each has its
own set of LEDs. BUT right now, address 0 is used for
enabling/disabling the trigger supervisor (type beam_gate_on or
beam_gate_off). So it's best to use address 1 to test the CAMAC
dataway; otherwise you might inadvertently disable data taking. If you
have power-cycled/cleared/initted the crate, the output register will be
set to 0, and triggers will be inhibited until you type beam_gate_on

5) If power-cycling/clearing/initting the CAMAC crates and resetting the
VME-to-CAMAC interface doesn't work, I'd try rebooting and/or
power-cycling the VME crate. Only if that failed would I start
reseating the branch highway cables. The cables are reasonably
well-supported, so we shouldn't have dropped bit problems develop,
unless someone has really been pushing on those cables.

                                        Karen



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST