deviceaccess-modbusbackend

Client supporting tcp and rtu communication with modbus devices

https://github.com/chimeratk/deviceaccess-modbusbackend

Science Score: 57.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
    Found CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
    Found 3 DOI reference(s) in README
  • Academic publication links
  • Academic email domains
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (8.3%) to scientific vocabulary
Last synced: 6 months ago · JSON representation ·

Repository

Client supporting tcp and rtu communication with modbus devices

Basic Info
  • Host: GitHub
  • Owner: ChimeraTK
  • License: lgpl-3.0
  • Language: CMake
  • Default Branch: master
  • Size: 422 KB
Statistics
  • Stars: 0
  • Watchers: 5
  • Forks: 1
  • Open Issues: 1
  • Releases: 1
Created over 7 years ago · Last pushed 9 months ago
Metadata Files
Readme License Citation

README.md

Modbus backend

License DOI Supported Platforms

The modbus backend is based on the NumericAddressedBackend. This means registers are accessed via an address consisting of two parts ("bar" and "address"). Register addresses are specified in a map file (just like for any other NumericAddressedBackend including e.g. the PCIe backend), which looks typically like this:

#Name             #N_ELEMS    #ADDR  #N_BYTES  #BAR  #WIDTH  #N_FRAC  SIGNED  #ACCESS
holding.reg1      1           0      2         3     16      0        1       RW
holding.reg2      1           2      2         3     16      0        0       RW
holding.reg3      1           4      2         3     16      8        1       RW
holding.reg32     1           6      4         3     32      0        1       RW
holding.float     1           10     4         3     32      IEEE754  1       RW
holding.reg8      1           15     1         3     8       0        1       RW
holding.array     10          16     20        3     16      0        1       RW
input.reg1        1           1024   2         4     16      0        1       RO
coil.bit1         1           0      1         0     1       0        0       RW
coil.bit2         1           1      1         0     1       0        0       RW
coil.array        8           2      8         0     1       0        0       RW
discreteinp.array 10          0      10        1     1       0        0       RO
discreteinp.bit1  1           10     1         1     1       0        0       RO

For more details about the map file format, please refer to the DeviceAccess documentation.

The #BAR column represents the Modbus object type: - 0: Coil / writeable bit - 1: Discrete input / read-only bit - 3: Holding register / writeable register - 4: Input register / read-only register

This number is used as a leading digit of the address in most other Modbus applications, see Wikipedia.

The #ADDR column contains a byte address of the register counting from 0. Compared to the standard Modbus register number (16 bit registers and counting from 1) the difference is a factor of 2 and an offset of 1. Hence, in the above example holding.reg1 would be address 30001, while holding.reg2 corresponds to 30002 etc. For bits (bars 0 and 1), the address from the map file matches the Modbus register number apart from the offest of 1.

Since Modbus supports transferring mulitple registers with a single command, registers with a bigger width than 16 bits are possible (cf. holding.reg32 in the above example). In case the given byte address is not aligned with the Modbus 16 bit register width (cf. holding.reg8), a less-efficient unaligned transfer needs to be done, which involves read-modify-write in case of write operations.

Reads/writes of consecutive registers can be merged into single multi-register accesses. To disable this (e.g. for broken Modbus servers), the parameter disableMerging can be set.

The fixed-point resp. floating-point conversions specified in the map file are executed just like for any other NumericAddressedBackend. If no conversion is required for a standard 16-bit Modbus register, specify the "#WIDTH #NFRAC SIGNED" columns as "16 0 1" for signed resp. "16 0 0" for unsigned registers. The specified bit width must not exceed the bit width of the register, i.e. if #NBYTES is e.g. 2, #WIDTH must be <= 16.

The CDD (ChimeraTK device descriptor) syntax (as used e.g. in the DMAP file) is as follows:

  • TCP mode: (modbus:myserver?type=tcp&map=device.map&port=502)
  • RTU over TCP mode: (modbus:myserver?type=tcp&map=device.map&port=502&slaveid=2)
  • RTU mode: (modbus:/dev/ttyUSB0?type=rtu&map=device.map&parity=N&baud=115200&data_bits=8&stop_bits=1)

As can be seen in the example above two types of modbus communication are supported: - type: rtu - type: tcp

Both offer different additional parameters. If no parameters are given the following defaults are used:

  • rtu:
    • parity = N (other allowed values are E or O)
    • baud = 115200
    • data bits = 8
    • stop bits = 1 (other allowed value is 2)
    • slaveid = 1
    • disableMerging = 0
  • tcp:
    • port = 502
    • slaveid = 255
    • disableMerging = 0

Owner

  • Name: ChimeraTK
  • Login: ChimeraTK
  • Kind: organization

Control system and Hardware Interface with Mapped and Extensible Register-based device Abstraction Tool Kit

Citation (CITATION.cff)

# This CITATION.cff file was generated with cffinit.
# Visit https://bit.ly/cffinit to generate yours today!

cff-version: 1.2.0
title: Modbus device backend for the ChimeraTK framework
message: >-
  If you use this software, please cite it using the
  metadata from this file.
type: software
authors:
  - given-names: Klaus
    family-names: Zenker
    affiliation: Helmholtz-Zentrum Dresden-Rossendorf
    orcid: 'https://orcid.org/0000-0002-8120-6806'
  - given-names: Matrin
    family-names: Hierholzer
    affiliation: Deutsches Elektronen-Synchrotron DESY
    orcid: 'https://orcid.org/0000-0003-2285-1319'
identifiers:
  - type: doi
    value: 10.14278/rodare.3263
repository-code: 'https://github.com/ChimeraTK/DeviceAccess-ModbusBackend'
abstract: >-
  The modbus device backend implements a modbus client, that
  allows to create an ChimeraTK device that communicates
  with a modbus server. The implementation is based on the
  open source library libmodbus.
keywords:
  - ChimeraTK
  - Modbus
  - Control System
license: LGPL-3.0-only
commit: >-
  https://github.com/ChimeraTK/DeviceAccess-ModbusBackend/commit/d7c7d9a50468f73e5ca772e081ddce2cc288e50e
version: 01.05.00
date-released: '2024-02-01'

GitHub Events

Total
  • Release event: 1
  • Delete event: 8
  • Issue comment event: 1
  • Push event: 10
  • Pull request review event: 3
  • Pull request event: 21
  • Fork event: 1
  • Create event: 11
Last Year
  • Release event: 1
  • Delete event: 8
  • Issue comment event: 1
  • Push event: 10
  • Pull request review event: 3
  • Pull request event: 21
  • Fork event: 1
  • Create event: 11

Issues and Pull Requests

Last synced: 6 months ago

All Time
  • Total issues: 0
  • Total pull requests: 8
  • Average time to close issues: N/A
  • Average time to close pull requests: about 4 hours
  • Total issue authors: 0
  • Total pull request authors: 2
  • Average comments per issue: 0
  • Average comments per pull request: 0.13
  • Merged pull requests: 8
  • Bot issues: 0
  • Bot pull requests: 0
Past Year
  • Issues: 0
  • Pull requests: 8
  • Average time to close issues: N/A
  • Average time to close pull requests: about 4 hours
  • Issue authors: 0
  • Pull request authors: 2
  • Average comments per issue: 0
  • Average comments per pull request: 0.13
  • Merged pull requests: 8
  • Bot issues: 0
  • Bot pull requests: 0
Top Authors
Issue Authors
  • mhier (1)
Pull Request Authors
  • mhier (10)
  • killenb (5)
  • phako (2)
  • zenker (1)
Top Labels
Issue Labels
Pull Request Labels

Dependencies

pyproject.toml pypi