Technical description

The system is based on standard PC-compatible computers running Microsoft Windows® NT 4 or Windows 2000®. Standard digital input/output (I/O) control hardware from an electrical engineering company is used, along with Windows-compatible multimedia devices (in Multimedia editions of Whisker). Proprietary hardware has been avoided to minimize cost.

The Whisker server controls the digital I/O and multimedia hardware directly, and treats each input and output line as a resource to be managed. Clients communicate with the server (via the TCP/IP network protocol) and may request the use of a set of I/O lines, typically to control one or more operant chambers. Each client then instructs the server to switch output / control lines on or off, and asks to be informed of certain events. The client declares which events it wishes to be told about. For example, it may request to know about any of the following events: an input / response line goes on or off, an area of a touchscreen is pressed, or a certain time has elapsed. With this information, each client can implement a behavioural task.

This system was adopted in order to enable independent and different tasks to be used simultaneously without restricting the clients to a pre-specified programming language, as this can only reduce the flexibility of the system.

The inner workings of the system are described in full in the Programmers Guide so that you can program your own behavioural tasks with it if you choose.

Advantages

The use of a TCP event-driven server brings the following advantages:

It enables client applications to be written in any programming language that can use TCP communications. Users are therefore not tied to a particular language, client applications can be as sophisticated as you wish, and programming skills will transfer to other tasks. You can use a compiled language so that syntactic errors are picked up before you go live.

2.	The server and clients can run on different computers if desired (though this relies on good network performance for real-time control).

3.	Applications that are already geared towards TCP communications will readily lend themselves to further extensions. One such feature built into the system is the ability to find out your subject's progress, or even to control a session, from another computer in a remote location.

4.	The communications system is designed for easy, logical programming. Particular attention was paid to avoiding the potential for programming errors that are common in some other operant control systems, such as conflicts between timers.

The system can run different client applications simultaneously, allowing different tasks to be used in different boxes at the same time. While applications may be written to control (say) four boxes simultaneously, it is easier and more useful to write a task for a single box; the system will then run four copies of this task and so every task written for the system allows boxes to be run asynchronously without special programming. You can even use one chamber for writing and debugging a new task without fear of disrupting the other chambers.

Other helpful features:

6.	Behavioural tasks can be expanded to include functionality not supported by more specific pre-defined languages. For example, many clients in use within the Cambridge laboratories file their data directly into a relational database, as well as saving a human-readable account of the data.

The server allows certain output/control lines to be given special properties: Failsafe lines are used to ensure that the digital i/o system reverts to a safe state if there is a catastrophic failure (e.g. power loss to the computer). Safety timers can be set for any output/control line to ensure that a design flaw or communication loss with a client does not leave the system in a dangerous state for longer than a specified time. These features may be used with IV pumps, shock generators, etc.

Extensive support for the commonly used languages. The Software Development Kit for Whisker provides support to allow tasks to be very quickly and easily developed in the commonest languages: VisualBasic & C++. These tools can also be used in other RAD environments (such as Delphi, C#) which support the ActiveX model.

The computers are standard PC running Microsoft Windows®, so they can be used for other tasks (word-processing, data analysis) when not running behavioural tasks. Depending on your system's speed, you may even be able to use the PC for other things when it is running behavioural tasks. You can connect your operant control computers to your local area network to move data around the network, print to remote printers, etc.

Note: Advanced clients

•	Clients could be written to implement any possible function, such as to interpret other popular behavioural control languages (e.g. there is no technical reason why a client could not be written to interpret Arachnid programs, or Med-PC® scripts).

•	Clients do not have to run on the same machine as the server. They do not even have to run under the same operating system; while the server is Windows-based, clients could run under UNIX or any operating system that supports TCP/IP.

Limitations

Limitations of the system:

Typically, clients run on the same computer as the server; thus task responsiveness depends on the speed with which TCP messages get sent from one program to another within the computer. Whisker provides facilities to monitor this performance, and we consistently achieve time resolution within 1 or 2 ms. However, as with any multitasking system, very heavy processing loads can slow this down for brief periods - although resolution of >10ms is extremely rare. However, it is inadvisable to run other software at the same time as the operant control system until you have checked the effect of this software on your system's performance.

If the control computer is connected to a network (this is not a requirement for the WhiskerServer, but is required to take advantage of the network functions such as remote monitoring) it is potentially vulnerable to denial-of-service attacks from other computers on that network. If that network is part of the Internet, the range of potential attackers is large. This problem applies to any networked computer, not just the Whisker system, but the data collected via Whisker is likely to be very important to you! Similarly, it is a matter of choice whether you allow computers outside your network to connect to your Whisker servers. (By default, other computers are allowed to ask the server for status information, but not to gain control of any digital I/O hardware.)

Features not currently implemented:

1.	A limited range digital I/O hardware is presently supported (Amplicon PC272 & PC272E cards and, as of version 2.4.0, Advantech PCI 1753 cards).

2.	Devices other than simple digital I/O lines – for example, serial communications or analogue control – are not presently supported, although support for these devices is under development.

Clients must be independent, stand-alone programs, requiring users to have programming skills, although the choice of such languages is wide. (This was a deliberate design feature, to make the system as powerful as possible.) At present, there is no 'special' client that would allow you to design behavioural tasks in graphical form with no programming skills, but such a client could be written.