Experimental Physics and
Industrial Control System

Hi John,


Some questions:


- What version of asyn are you using?

- Are you using relative or absolute Modbus addressing?

- Is this Modbus TCP over Ethernet?

- For the records that generate the alarm, what is:

    - The record type

    - The Modbus function code

    - The SCAN rate

    - The polling rate of the modbus driver

    - The time between alarm status changes

- Is it possible for you update to modbus R3-0 and see if the problem persists?  It will make it easier for me to fix if you are running the latest release.


The alarm status is set according to the status returned by the function doModusIO().  The driver should only do callbacks with a new alarm status when that status return changes.


It would probably be a good idea to turn on asynTrace of the underlying asynIPPort driver and see if its status is changing.


Mark



________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of John Dobbins via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, July 8, 2020 11:54 AM
To: tech-talk at aps.anl.gov
Subject: Modbus alarms question

All,

We have a PLC from which data is read by an IOC via Modbus (R2-11).  The PLC was turned off and while the PLC was off the IOC generated a stream of alarm messages from the Alarm Server (BEAST) while the PVs toggled between

SEVERITY: INVALID           STATUS: READ_ALARM

and

SEVERITY:  INVALID           STATUS: TIMEOUT_ALARM

Aside from configuring these alarms to be latching in the Alarm Server configuration is there some other way to make it so this state (loss of modbus communication) doesn't generate a stream of alarms?

Regards,

John Dobbins

Research Support Specialist
Cornell High Energy Synchrotron Source
Cornell University

www.chess.cornell.edu