Skip to content

Abstraction of libCom

Karol Krizka requested to merge libcom into devel

Addresses issue #5 and #26 .

Introduces a ICom interface class that defines common functions for sending/receiving data to a device independent of the actual connection hardware. They are:

  • send: send data
  • receive: read available data
  • sendreceive: send and read data

The input and output data can be specified either as std::string or a c-string.

Locking Mechanism

All communication functions (send/receive/sendreceive) are required to be multi-process safe and reentrant. That is, no other communication with the device from a different process is allowed until the function completes. To help this, the following interface functions are required:

  • lock: Request a lock on the communication hardware
  • unlock: Release a lock on the communication hardware

The lock/unlock functions are declared as public for applications to obtain an exclusive lock across multiple consecutive commands.

Configuration

The ICom instances can be configured using JSON objects via ICom::setConfiguraton. The available keys are documented in the setConfiguration descriptions for the corresponding implementation.

The equipment configuration is now responsible for initializing these classes as part of getPowerSupply. It uses the ["communication"]["protocol"] as a name of the class (ie: "SerialCom") to identify the right implementation. There is also now a ComRegistry containing all ICom implementations.

Changes to IPowerSupply

The IPowerSupply implementations are no longer responsible for creating their own communication. This is now handled by the equipment registry configuration. Instead a IPowerSupply::setCom(std::shared<ICom> com) function is added that sets the m_com protected variable to a configured ICom object. This is then available to all power supply implementations.

The setCom replaces the connect function. The setCom also checks that the communication is correct (also previous behavior of connect). This is done in a model-independent way by calling a new pure virtual function called IPowerSupply::ping() that should return true if a test command was successful.

Also added implementation of AgilentE36300APs power supply.

Available implementations

The following ICom implementations are available:

  • SerialCom: Communication via serial ports
  • TextSerialCom: Communication via serial ports using \n\r delimitated text strings
  • GPIBSerialCom: Communication via serial ports using \n\r delimitated text strings with GPIB addesses setting
  • CharDeviceCom: Communication via character devices

Other

There are a few changes to how the serial communication behaves.

  • Removed sleep between write and read calls in command as it was a rather arbitrary time.
  • The device is opened in a blocking manner. Thus we don't read a device until the data has been sent. We might require checks that all data has been received (ie: see a \n\r in returned data for TextSerialCom)
Edited by Karol Krizka

Merge request reports

Loading