Experimental Physics and
Industrial Control System

Patricia Rose <[email protected]> · Tue, 14 May 96 16:20:24 CDT

>Holger B. E. Jones <[email protected]>
>Imaging and Detection Program
>Lawrence Livermore National Lab L-437
WROTE:
>Just completed a mail transaction with Bob Delesio concerning EPICS support
>for the Modicon PLC. I'm trying to understand the issues involved and am
>wondering if you can tell me the status of your work.

/*--------------
James F. Harrison <[email protected]>
ANSWERED:
Pat Rose is doing the work on this project.  A preliminary version of the
Modbus+ driver and device support is somewhat customized for our
installation in order to get something working for our site.  Pat has analog
and binary input working and analog output working.  She is close to having
binary output working.  We plan for the next version to have more general
features which would be easier to adapt for other sites.
(Pat, please feel free to expand on this reply.)
/*--------------
Bob Dalesio < [email protected] >
ASKED:
Is this full duplex - or synchronous communication with the PLC?
/*--------------

Pat answers (finally!):
Bob's question first....  The driver is asynchronous and as full duplex as
you can get it given the Modbus Plus protocol. I'm not sure what the
original discussion entailed; therefore I will give some background.

There are basically two ways for a host computer to communicate with the
Modicon PLC's, Modbus or Modbus Plus.  Note: there is a standard messaging
protocol called (just to confuse the issue) Modbus.  Both Modbus and Modbus
Plus use this messaging protocol.

Modbus communication is via standard RS232 using either 7-bit ascii (Modicon
calls this ascii) or full 8-bit binary (RTU).  You can use a standard
terminal driver for this type of communication.  There was a good discussion
(tech-talk)on how to impliment a driver for Modbus:
        From: [email protected]
        Subject: Re: MODBUS
        Date: Wed, 19 Oct 94 10:13:19 -0500

We have implimented a driver for Modbus Plus. It uses the SV85 board for
communication with Modicon PLC's; it reads and writes the Modicon registers.
It is not used for programming the PLC or performing any functions over the
"PM" or "PS" data paths.

(As an aside, I got my leg up on the original board initialization from
[email protected] (Bill Brown) and had quite an extensive e-mail discussion
with John Dalesio of Tate.)

The "driver/device support" consists of three modules.  There is a module
for supporting the SV85.  This module contains the code for communicating
through the SV85 on Modbus Plus.  It has the routines for locking/unlocking
the dual ported RAM on the board, handling message traffic, interrupts,
service requests, etc.  This module contains the code for initializing the
board.  This module also starts up two processes: 1)a process for "scanning"
all the registers that are of interest to the ioc & for writing PLC
registers; 2) a process for handling the service requests.  Each SV85
contains eight Data Master (DM) paths (as well as eight Data Slave, eight
Program Master, eight Program Slave paths).  For each block of registers to
be scanned, or each PLC register to be written, a DM path is allocated, a
formatted message is copied to the Dual-port ram, the board is instructed to
send the message.  At some later time, a service request interrupt occurs.
The reply message (as defined by the Modbus message protocol) is retrieved
from the board, driver support is called to "process" the message, the DM
path is de-allocated, etc.

The driver support contains the code for formatting requests for scanning
registers, for sending commands, etc.  It also handles the reply messages,
copies the scan buffers, checks the buffer for changes, declares io
interrupts, etc.

The device support is fairly standard device support.  Most of the code
simply hands off work to the driver.

The driver is certainly NOT READY FOR PRIME TIME!  The majority of error
handling consists of a logmessage followed by suicide (a la MASH).  There is
currently a module that defines tables of registers to be scanned
statically; they are not built dynamically.  Initialization is done outside
of iocinit.  Interrupt vectors and base addresses are not registered with EPICS.

And last but not least...
1)When you do a read you do not get the current PLC register value (which
you can never see directly), you don't even get the value as it would be
seen if you requested it now; you see only the value as it was the last time
you requested to see it.  (Now that I have commands, implimenting a "read
Immediate" would be simple).
2)a Binary output that is in a 4xxxx register does not use an inter-locked
read/modify/write cycle; the last scanned value is modified and sent.  This
should work for our application, for now, but...  The Next Version will have
some sort of read/mod/write, possibly inter-locked.
3)The driver does not have any "this is off-limits" checking on commands.  TNV
4)Also, our read-back channels for output records are not necessarily in the
same register.  There are some output channels that are effectively write
only.  (This is really the reason commands aren't done.)
5)Comments are lacking...

The Next Version...RSN.  I plan to use the driver as transportation to EPICS
collaboration meeting in the fall.
----------------------------------------------------------
Patricia A. Rose           email: [email protected]
Los Alamos National Lab    office:(505) 667-6749    
DX-7, MailStop P942	   FAX:   (505) 665-4396
Los Alamos, NM 87545

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System