If you are seeing this message either you are a guru who has a custom browser setting, or your browser is out of date and cannot handle some of the more recent Web standards. In our opinion this site would look much better with the standard setup of a modern browser. However we intend it to be accessible to any browser or Internet device.

Software Structure

This page describes the architecture of the Bugblat software system. It will be of interest to anyone who would like to know how things work 'under the hood' and to potential users of the Bugblat user-level programming interface.

The software which supports the Bugblat products is structured as a series of layers:

1. an application layer, usually a graphical user interface (GUI). For most users this will be the bbx.exe program, which handles the buttons, menus, list, and so on, and draws the waveforms and other displays.
2. the GUI plugs into control logic through which it can drive the instrument and receive sample data and status information. In our terminology, this is the Client software. For instance, when a user presses the run button, the GUI will
   • call the Run routine in the Client software
   • periodically query the Client software to see if the instrument has completed a sample acquisition.
3. The Client software plugs into Server software which understands how to manipulate the internals of the instrument's hardware. The Server software knows nothing about the application. Continuing the previous example, when the Run routine is called the Client layer tells the Server layer to
   • set bit 0 in register 17 to 1.
4. Finally, the Server software drives the instrument's hardware via a USB Interface layer which is a thin software layer round the drivers for the USB chip. Continuing the previous example, the Server layer tells the USB Interface layer to send the following down the USB link:
   • the code for 'this is a register address'.
   • the value 17.
   • the code for 'this is data for a register'.
   • the value 1.

Local and Remote Operation

Most users want to control a single instrument plugged into their own computer -the computer on which the GUI is running. But sometimes an instrument has to be controlled across a network. Usually the network is the Ethernet within an organisation, but it could be right across the Internet. This section describes how the software supports Local and Remote alternatives.

The key is the interface between the Client layer and the Server layer. Logically the same in Local and Remote operation, this interface is implemented quite differently in the two modes.

Local Operation

The software inserts a glue layer between the Client and Server layers, as shown in the following figure:

The glue software turns off all networking functionality in the Server layer - the Server becomes a single-threaded module dealing with requests from the GUI and Client layers.

From the perspective of the GUI, the software for Local Operation is functionally identical to the software for remote operation. And it is a little more efficient because it doesn't have to deal with networking overheads.

Remote Operation

As before, the software inserts a glue layer between the Client and Server layers, but this time the glue is a TCP/IP communications path, as shown in the following figure:

In this case the Server is a multi-threaded module which will respond to simultaneous requests across the network from one or more GUI/Client stacks.

Experts will know that the Remote setup can also be used for local operation. This is because TCP/IP allocates a local loopback address (127.0.0.1) to every computer. By convention, the loopback interface is also known as localhost. So by using the remote software to connect to either localhost or 127.0.0.1, you will be connecting to an instrument on your own computer.

Program Modules and Libraries

The GUI module is bbx.exe - the same in all cases. And it always interfaces to the bbxif.dll support library, which implements the Client software layer. bbxif.dll also contains software which optionally implements the Server and USB Interface layers, as described below.

Both bbx.exe and bbxif.dll are installed as default when the standard installer is run.

Local Operation

If bbx.exe and/or bbxif.dll is fired off without the name of a remote computer, bbxif.dll configures itself as shown below.

In this mode, bbxif.dll implements all the Client and Server routines needed to bridge between the bbx.exe GUI and the instrument's hardware.

Remote Operation

On the other hand, if bbx.exe and/or bbxif.dll is fired off with the name of a remote computer, bbxif.dll configures itself as shown below.

The Server routines inside the local bbxif.dll are not used. Instead the Client software communicates with Server routines in a program across the net. Typically, this program is bbxserve.exe.

The Interface DLL - bbxif.dll

bbxif.dll is part of the standard support software and it is installed as default when the installer is run. It can also be downloaded here.

The Server Program - bbxserve.exe

These options are available for Server/USB Interface software which drives the Ants over USB links:

• bbxif.dll includes the optional single-threaded local Server.
• a Server program running on the same computer.
• a Server program running on a connection across a network.

If the built-in Server is not used, you will need a separate standalone Server. The bbxserve.exe program is a multi-threaded TCP-driven version of the built-in Server, with the addition of a small control GUI. bbxserve.exe is available here. The zip file includes source code and a runnable program.