Chapter 43. The ccusbcamac tcl package

43.1. Overview

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.

43.1.1. Goals

  1. Interactive access to CAMAC devices through a tcl interpreter.

  2. Backwards compatibility to wienercamac and camac packages.

43.1.2. Interactive Control

The ccusbcamac can be loaded into any TCL interpreter using the

package require ccusbcamac
command. 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.

43.1.3. Backwards compatibility

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:

  1. The namespace is ccusbcamac

  2. Additional information needs to be provided to define the location of the slow-controls server.

43.1.4. Migrating to ccusbcamac

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]



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.