Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 9 Apr 2007 14:02:31 -0500

Hi David,

I have made a start on the documentation for my software at:

http://cars.uchicago.edu/software/epics/modbusTCPDoc.html
http://cars.uchicago.edu/software/epics/modbusTCPReleaseNotes.html
http://cars.uchicago.edu/software/epics/modbusTCP.html

The device support is completely generic, it knows nothing about Modbus.
This is because it is the 3,500 lines of code that comes with asyn
itself.  My driver just implements the standard interfaces, like
asynInt32, asynInt32Array, etc.   

The driver is basically a thin interface between the asyn device support
and the asyn TCP/IP driver.  It builds and decodes the Modbus messages.

It would be very easy to make my driver also handle serial Modbus.  It
would just build a generic Modbus packet, and then put the TCP/IP header
on at a later stage.

Do you know if Koyo PLCs from Automation Direct support Modbus serial?
They do support Modbus TCP, that is what I have been using for testing.

My driver architecture lends itself to doing what you want, replacing
the protocol by just changing a relatively small driver layer.

Mark

> -----Original Message-----
> From: David Dudley [mailto:[email protected]] 
> Sent: Thursday, April 05, 2007 12:04 PM
> To: Mark Rivers
> Cc: [email protected]
> Subject: RE: ASYN Octet driver question
> 
> 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