https://github.com/matham/barst
A server that controls lab hardware.
https://github.com/matham/barst
Last synced: about 1 year ago
JSON representation
A server that controls lab hardware.
- Host: GitHub
- URL: https://github.com/matham/barst
- Owner: matham
- License: mit
- Created: 2014-05-15T01:39:22.000Z (about 12 years ago)
- Default Branch: master
- Last Pushed: 2019-10-25T03:33:40.000Z (over 6 years ago)
- Last Synced: 2025-02-15T04:26:10.672Z (over 1 year ago)
- Language: C++
- Size: 589 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
Barst
======
Barst is a server/client architecture for reading/writing to
devices, such as switches or cameras commonly used in the CPL lab.
It allows one central server to control the devices, while clients
request that data be sent or read from the devices.
See http://matham.github.io/barst/index.html for the complete
server documentation and https://matham.github.io/pybarst/index.html
for a Python client implementation.
Note that the project does not link to any external code at compile time
but instead loads driver dlls dynamically at runtime. Therefore,
these dlls needs to be present and installed on the system before
specific devices can be supported.
Usage
-----
Users typically instantiate a server instance from a batch file with e.g.
start "" "barst.exe" "\\.\pipe\CPL_test" 1024 1024
in a batch file. Once instantiated, users interact with the server using
the client API over the provided pipe.
Architecture
------------
Each device supported by the server requires that a ``CManager`` and ``CDevice``
interface to be implemented. This defines the operations supported by the device.
A client first requests the manager for a particular device type, e.g. the ``MCDAQ``
(Measurement Computing USB DAQ) using the main server pipe. The first time the manager
is created on the server, it loads the required driver. Subsequently, the client
sends a request to the manager to create an instance of a specific ``MCDAQ`` device.
Once the ``MCDAQ`` device exists, clients connect to it directly (each device gets its own
pipe) and send data requests to control or read from the device. Multiple clients
may safely send requests to the same device. Each device reads or writes data in its
own thread.
For reading data from the device, there are generally two options:
#. Read the device and send back data to the client upon request.
#. The server contentiously reads data from the device and buffers it. It also
contentiously sends the data it read to the client who initiated the read
request.
Clients are responsible for closing the device when not needed anymore.
Data types
-------------
All data requests over the pipe start with common structs. Each device manages
the pipe used by clients of the device and defines the structs used by clients.
``cpl defs.h`` defines all the data types.