Experimental Physics and
Industrial Control System

"David Dudley" <[email protected]> · Thu, 05 Apr 2007 12:04:23 -0500

Sorry, I've been occupied with killing a bug (in another project) for a
few days.

At the current moment, it's probably a little too early for me to work
on combining this with anything else.  I'm changing things so often
right now that from hour to hour I have some fairly large changes
incorporated, and would just destroy anything that I'm not intimately
familiar with at the moment.

However, a little background is in order.
My driver is basically broken up into 2 levels.  There's a 'hardware
independent' layer that is the actual 'dev' portion of the driver.  That
portion is responsible for interfacing with the upper levels of EPICS,
allocating cache blocks and buffers, and in general generating all the
data information that the driver layer itself needs.  I've worked
particularly hard to insure that this layer doesn't know what kind of
PLC it is connected to, or even the details of the protocol driver
itself.
When a request is made to this layer, it simply loads a set of
information into its device independent section, and passes it through
the ASYN interface to the driver portion itself.

The driver portion handles the actual client transaction.  It is
responsible for communicating with the PLC, receiving and verifying the
response, and passing any information back through ASYN to the dev
layer.  It knows all about the PLC, how it's connected, how data gets
passed, endian information, etc...

I've done things this way because I actually need to write several
drivers, and I want to reuse as much programming as possible.
I need to develop drivers for modbusSerial, modbusSlave, Siemens/TI
NITP, Siemens/TI TBP, and NMEA 503.  I'm working on setting things up so
all I need is to replace the driver portion with the appropriate
protocol driver, and the upper levels of the device itself work
correctly.

ModbusSerial is by far the most common PLC and instrumentation protocol
around.  Almost any PLC that has a serial port on it will have it in
addition to whatever else they support.  Most field instrumentation
(like process analyzers and remote instrumentation) has either modbus or
HART available, but HART requires some specialized communications
hardware to communicate with.  We use it here in the Corpus Christi
Water system for everything we can, preferring by far to use it instead
of discrete contract closures and current or voltage loops, since you
can get much more information through it almost always.

At the treatment facility, we have Allen Bradley, Siemens, Modicon,
Motorola, Automation Direct, HACH, and a few other types of PLCs and
instrumentation, and regardless of what we have, they all support modbus
as a common communications thread.

David Dudley

>>> "Mark Rivers" <[email protected]> 3/30/2007 5:18 PM >>>
Hi David,

I wonder if it makes sense to combine our efforts?

My driver uses the standard generic asyn device support.  It supports
many standard records.  It supports I/O Intr scanning via callbacks on
reads.  It supports binary and BCD data types, and has lots of nice
features.

There is only one function that is specific to TCP, and I could easily
break that into 2 parts:  one that builds a basic Modbus message, and
another that puts the TCP-specific header on it.  That way one driver
would support both serial and TCP.

My driver is working, but the documentation is not done.

Does serial Modbus use standard asynchronous serial hardware, or are
special synchronous hardware drivers needed?  What kinds of PLCs use
serial Modbus?

Mark

> -----Original Message-----
> From: David Dudley [mailto:[email protected]] 
> Sent: Thursday, March 29, 2007 7:18 AM
> To: [email protected] 
> Subject: RE: ASYN Octet driver question
> 
> This is a serial modbus driver.  It supports AI, AAI, AO, AAO, BI,
BO,
> MBBI, MBBO, StringIn, and StringOut.  I'm going to add 
> Waveform support
> to it as well.  Right now, I seem to have an intermittent 
> problem where
> it will just start timeing out messages after a while, and I 
> get quite a
> few communications failures that I don't think I should have.  I
think
> it's a problem with the asyn thread communicating callbacks with the
> database thread.
> 
> David Dudley
> 
> >>> "Mark Rivers" <[email protected]> 3/28/2007 9:06 PM >>>
> David,
>  
> "... queueRequest Priority 1 not lockholder...", 
>  
> The messages you are seeing are normal, they do not indicate 
> an error. 
> I think we should change the messages so that they look less like
> errors.
>  
> Here is the output of a serial device that is working normally, with
> all asynTrace flags set to 1.
>  
> 2007/03/28 19:54:24.184 serial1 addr -1 queueRequest priority 0 not
> lockHolder
> 2007/03/28 19:54:24.184 serial1 schedule queueRequest timeout
> 2007/03/28 19:54:24.184 serial1 callback
> 2007/03/28 19:54:24.184 13BMA:ip1_serial: asynCallbackProcess,
state=3
> 2007/03/28 19:54:24.217 serial1 flush2007/03/28 19:54:24.267 serial1
> flush
> 2007/03/28 19:54:24.300 13BMA:ip1_serial flush
> 2007/03/28 19:54:24.350 serial1 write.
> 2007/03/28 19:54:24.384 serial1 write 3 RD\r
> 2007/03/28 19:54:24.434 serial1 write RD\r
> 2007/03/28 19:54:24.467 13BMA:ip1_serial: nwrite=2, status=0,
nawt=2,
> data=RD
> 2007/03/28 19:54:24.550 serial1 read.
> 2007/03/28 19:54:24.600 serial1 read 36 RD\023\n\r19 09:38 5400V
> 8.2E-5I H---23\n\r
> 2007/03/28 19:54:24.684 serial1 read RD\023\n\r19 09:38 5400V
8.2E-5I
> H---23\n\r
> 2007/03/28 19:54:24.767 serial1 read.
> 2007/03/28 19:54:24.867 serial1 read 1 \021
> 2007/03/28 19:54:24.867 serial1 read \021
> 2007/03/28 19:54:24.900 13BMA:ip1_serial: inlen=40, status=0,
ninp=37,
> data=RD\023\n\r19 09:38 5400V 8.2E-5I H---23\n\r\021
> 2007/03/28 19:54:25.034 13BMA:ip1_serial: inlen=37,
> nbytesTransfered=37, ntranslate=47 
> 
> By the  way, you said you are working on a Modbus driver.  Is this
> serial, or  Modbus TCP?  I am just about to release a package 
> for Modbus
> TCP that uses asyn for the TCP I/O, and asyyn device support. 
>  I hope to
> release it by  thee end of the week.  I'l send a note to 
> tech-talk when
> its ready.
>  
>  
> Mark
>  
> ________________________________
> 
> From: David Dudley [mailto:[email protected]] 
> Sent: Wed 3/28/2007 2:29 PM
> To: [email protected] 
> Subject: ASYN Octet driver question
> 
> 
> 
> I'm trying to solve a problem with the ASYN Octet package in my
Modbus
> driver.  When I have tracing turned on, I get exceptions every time
I
> try to write or read something, that say "... queueRequest Priority
1
> not lockholder...", and then "...queueRequest timeout...".
> However, the requests still get processed (most of the time....).
> 
> Trying to track down what this "...not lockholder..." message is
from.
> I look through my code, and I don't see anything where I'm calling
the
> "asynManager->registerPort" routine, nor do I see anything that
> references it.  Would that cause this problem?
> 
> David Dudley
> 
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System