The tcl ccusbcamac package provides a mechanism for the user to send single-shot operations to a remote Wiener CC-USB device controlled by a CCUSBReadout program. The package provides a workaround for the restriction demanding that only one process can communicate with a USB device at any given time. The ccusbcamac package interacts with the slow-controls server of the CCUSBReadout program to remotely execute commands.
Interactive access to CAMAC devices through a tcl interpreter.
Backwards compatibility to wienercamac and camac packages.
The ccusbcamac can be loaded into any TCL interpreter using the
package require ccusbcamaccommand. For best performance, the user should avoid trying to send interactive commands to the CAMAC device while the CC-USB is in data acquisition mode. When the command is received by the slow-controls server, the CCUSBReadout program will exit acquisition mode, drain the device of data, execute the command, retrieve the resulting data caused by the command, and the reenter acquisition mode. Altogether, that process takes a couple seconds. On the other hand, if the user issues commands while the device is not in acquisition mode, the device will respond almost immediately.
The package is is nearly a drop-in replacement for the wienercamac and camac packages designed to work with the SBS Bit3 device. Backwards compatibility means that the same API has been provided that was provided by those packages. There are two major difference between the former packages and this package:
The namespace is ccusbcamac
Additional information needs to be provided to define the location of the slow-controls server.
This section addresses the scenario of a user who has a functional tcl script that can control some CAMAC devices via one of the wienercamac or camac packages and wants to migrate to a CC-USB system.
The first step that the user needs to take to convert their script is to convert the namespace of the former package to ccusbcamac. Because there is a one-to-one mapping between the commands in the former packages to the ccusbcamac package, this amounts to a search and replace.
The second step that the user must take to migrate is to provide some
information about the slow-controls that will mediate the interaction with
the CC-USB device. To properly interact with the slow-controls server, it
is essential that the server can be connected to. For that reason the user
must provide the hostname on which the server is running and the port on
which it is listening for connections. Also, a plug must be loaded into
the server to handle the requests. This plugin is just name of the ccusb
module loaded in a ctlconfig.tcl script. These three pieces of information
must be provided to the ccusbcamac
package before ever trying to execute commands. The means for providing
these data is through the ccusbcamac::cdconn proc.
The ccusbcamac::cdconn proc must be called prior to
the calling of the ccusbcamac::cdreg (or any other
proc taking arguments b and c) for a specific set of b and c
indices. The information provided by the
ccusbcamac::cdconn are the following:
ccusbcamac::cdconn [b] [c] [host] [port] [module]
where
branch index
crate index
name of host on which the slow-controls server is running
port on which the slow-controls server is listening
name of ccusb module loaded into the CCUSBReadout program
The host, port, and module arguments should be clear after the earlier
discussion. However, you may be wondering what the branch and crate
indices refer to in a CC-USB system where there are no physical CAMAC
branches. Together, a set of branch and crate indices identify a
specific CCUSBReadout slow-controls server or analogously a specific CC-USB
device. There is no limit to how many slow-controls servers a single script can
interact with and the user can easily target a server to receive a command
with the b and c indices. You can imagine then that the purpose of the
ccusbcamac::cdconn proc is to bind a set of b and c
to the information for a slow-controls server.