| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Modbus alarms question |
| From: | John Dobbins via Tech-talk <tech-talk at aps.anl.gov> |
| To: | Mark Rivers <rivers at cars.uchicago.edu> |
| Cc: | EPICS tech-talk <tech-talk at aps.anl.gov> |
| Date: | Wed, 8 Jul 2020 18:58:54 +0000 |
|
Mark
Thanks. I'll start by upgrading to latest version and do a new test. After the test I'll send all the details.
John
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, July 8, 2020 1:38 PM To: John Dobbins <john.dobbins at cornell.edu> Cc: EPICS tech-talk <tech-talk at aps.anl.gov> Subject: Re: Modbus alarms question 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 |