Hello Colleagues,
We use a type of distributed I/O device that talks Modbus TCP/IP
called an Acromag 952EN-4012. We have had re-occurring issues with
these devices over the last few years. Most recently, we have
experienced the devices losing communication with our EPICS IOC.
We believe we have traced the source of this problem down to a
Port checking procedure that we were doing. This procedure simply
involves processing an asyn record that is linked to the IP Port
created for modbus access.
The simplest example of an IOC that produces these errors is
created with the following start up file:
drvAsynIPPortConfigure("ReadPort","192.168.0.78:502",0,0,1)
modbusInterposeConfig("ReadPort", 0, 1000,0)
dbLoadRecords("db/PortCheck.vdb")
With PortCheck.vdb being:
record(asyn, AcroRead) {
field(PORT, "ReadPort")
field(TMOD, "Write/Read")
field(SCAN, "1 second")
}
We usually read the .ERRS and .CNCT fields on AcroRead to check
the port, but I left that out of the epics code b/c it doesn't
appears to make a difference.
When AcroRead processes, we think the CPU (0.182) sends a "PSH" or
Push Command to the Acromag Device (0.78) [See attached wirehshark
file Acroamg_Port_Check_Tech_Talk]. After acknowledging this
packet, the Acromag device responds with an exception. It appears
to not understand the "PSH" command. I've spoken with Acromag
Engineers and they said their devices will not know how to process
this command.
We are fairly certain that this process, when combined with the
reads and writes we do, will intermittently cause the Acromag
device to stop responding completely to the EPICS IOC.
My question: Is the "PSH" command being sent expected behavior in
this situation? What are the origins of this command?
Thanks very much for any help you can provide.
Toby
--
Tobin Weber
University of Washington
Fast Neutron Therapy
206-598-0485