4. Faster way to read state of DI and control of relay ?

Faster way to read state of DI and control of relay ?

  • H

    Hello

    We need a faster way to control relay and read the status of DI.

    Our setup is this:

    We have a C++ control software running with Neuron M503.
    We have a relay output that activates mechanical movement in actuator.
    We also have a digital input connected to limit switch in this actuator.

    So when movement is commanded via relay, we can verify that physical movement has been actually occured by reading an limit switch. Pretty normal setup.

    Now we are controlling relay with EVOK websocket call and also reading the status of digital input with evok websocket. But as our process is pretty fast, this current way of controlling output and reading input seems to be too slow for us, we would need more speed.

    From what I read from this forum, Modbus TCP could be the answer. But then in Github [1], it's marked as "Legacy".

    So is Modbus still viable solution for more speed ? Could we call Modbus TCP from our C++ software and get faster responses than websocket ?

    We also have an UI that uses EVOK via websocket (Node Red) and we would like to keep that as it is. So in ideal solution we could have both - "lower level" calls from our C++ with Modbus TCP and slower UI calls from Node Red with websocket to EVOK.

    Best regards,

    Henkka

    [1] https://github.com/UniPiTechnology/neuron-tcp-modbus-overlay

    0 1 Reply
  • administrators

    Hello @henkka,
    the ModbusTCP server is still actively developed and it is our most supported API. On Neuron and Axon, make sure you have the most up-to-date version of unipi-modbus-tools package, which you can find in our official repository: https://kb.unipi.technology/en:sw:04-unipi-firmware#apt_repository
    Then you can access the ModbusTCP server on 127.0.0.1:502. The documentation of Modbus Registers Map for each device is here: https://kb.unipi.technology/files:products:00-start

    If you need very fast access to the IOs (except 1-Wire), I would suggest you to take a look at the SysFS approach. You can find documentation of the endpoints here: https://git.unipi.technology/UniPi/unipi-kernel/blob/master/docs/sysfs-platform-unipi.txt

    Let me know, what you have picked.

    Best regards,
    Martin

    0

  • I took up the sysfs-based approach in my own (golang-based) project: https://github.com/mhemeryck/unipitt

    Basically, it does active polling on a series of files, representing the different inputs and pushes out an MQTT-event in case there's a change.

    0