SLControl is a computer system which was developed by Ken Campbell in the Moss laboratory at the University of Wisconsin-Madison to help perform muscle mechanics experiments.

The project was started with the sole intention of developing a replacement system for an existing (but very dated) setup used to perform sarcomere length control experiments. (More background information is available here.) However, the project has developed considerably since then and SLControl now runs a number of different experimental protocols and provides a variety of analysis tools.

Perhaps the most useful feature of SLControl is its ability to perform experiments under real-time control. In this mode, the motor position (and thus overall fiber length) is updated in response to measured changes in sarcomere length or muscle tension. The updates occur at a predictable rate and with a very short time interval (as little as 0.2 ms) between a change being measured in the feedback signal and a correction being made to the fiber length command voltage. Control can also be switched between different signals (force and sarcomere length) in the time interval between consecutively sampled points providing great flexibility in protocol design.

Real-time control is a task which is beyond the capability of most conventional computer systems (e.g. Windows, OS X etc.) which by their very definition share processor time between multiple applications. SLControl overcomes this difficulty by implementing all of the time-critical tasks on a separate processor (a DAP 5216a from Microstar Laboratories) installed in a PCI slot in the host PC. The board handles all of the ADC/DAC tasks and stores the output and input waveforms in on-board RAM, so that, once started, it does not need to communicate with the host PC until the experiment is complete. In essence, SLControl's task is simply to start the DAP running, and then handle the data passed back from the board once the recording has finished.

Communication between the board and the host PC is controlled by Microstar's Accel32 software. Once this is installed on the host PC, SLControl can create communication pipes (similar to streams in ANSI C) which enable it to interact with the DAP. In most instances, commands are passed to the DAP as ASCII text, data is normally transferred back to the PC in a binary format.

The board itself is controlled by commands written in Microstar's propietary scripting language DAPL 2000. SLControl's experimental protocols generate code in this format automatically and pass it to the DAP via Accel32. No user intervention is required (or is indeed possible with a compiled version of SLControl) at this stage and it is not strictly necessary for the end-user to understand the DAPL code to perform experiments. Nevertheless, those who are interested in learning more about the control algorithms can do so by accessing sample (annotated) code via the DAPL link.