Experimental Physics and
Industrial Control System

Zenon Szalata <[email protected]> · Fri, 17 May 2013 14:09:42 -0700

Hi Hermann-Josef,
Thank you for your insight and advice.

I am still looking how to achieve my goals using the Modbus support

module written by Mark Rivers.

Right now, I wish for a C++ class either like asynPortDriver, or perhaps

derived from it, which would have implemented the Modbus protocol and

which would do the basic input-output operations. With such class, one

could then create a more specific class suitable for the application at

hand, inheriting the basic stuff from the base class.

Thanks again,
Zen

On 05/17/13 02:14, Mathes, Hermann-Josef (IKP) wrote:

Hi Zenon,

I am facing similar problems with Beckhoff KL60x1 terminals accessed via
BK9050... but my software environment (read EPICS modules in use) seems to
be a bit different from yours.

If you want to follow your approach I guess it is the best to block the poll
routine, assuming it is in a separate thread and a mutex exits/can be
introduced. Maybe this is already foreseen in the modbus support module or
can be easily implemented.

In my case I was inspired by the EPICS modules of LCLS
https://confluence.slac.stanford.edu/display/LCLSControls/LCLS+Software+Pack
ages (follow the link EPICS modules), namely the modules ModbusTCPClnt and
Bx9000_MBT.

There the Modbus layer is responsible to read and write the complete process
image into/from memory and the next layer then accesses this buffer. As far
as I see, this can work easily for simpler terminals where you don't have to
access the 'hidden' registers. A positive side-effect of that is also that
your update period can be well below 100 milli seconds.

I you look into the way PLCs are usually working, there is always a sequence
like input -> processing -> output -> input -> ... etc. I guess if you want
to have a consistent view on the memory in the buffer assigned to a single
terminal you eventually have to double buffer it and synchronize read/write
operations between the buffers with the background updating thread. At least
this is the way I am planning to go with my final implementation...
In case of PLCs where one has only a single task, there is no I/O during
processing and they don't need the double buffering.

A guy from Beckhoff gave me the advice to exchange the complete process
image in a separate thread when I told them I'd like to use that stuff with
Linux (and not TwinCAT). But as a novice to all this stuff I didn't follow
that advice one year ago ;(

Good luck and best regards
Hermann-Josef

-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] Im
Auftrag von Zenon Szalata
Gesendet: Donnerstag, 16. Mai 2013 20:38
An: Mark Rivers; [email protected]
Betreff: Modbus

Hi Mark,
I am still working on an IOC to control stepper motors with Beckhoff
devices (KL2431 and KL2541).  I am using your modbus (R2.2) support module.
Beckhoff devices are called bus terminals.  A bus terminal has two types
of registers.
One is a small set, typically 2 and in the case of the KL25x1 terminals
3, that one can read from or write to directly.  Let's call them
visible.  The poll thread in modbus does IO to these registers.
The other type is what I call "internal" or invisible registers. One can
access these registers via the visible registers only. Hence, multiple
operations need to be performed on the visible registers to either read
from or write to an invisible register.
I find that while I am writing to one of the invisible registers, at
times the periodic reading from the visible registers in the poll
thread, interferes with the writing process.

I assume that I can control the poll timeout using your
poll_delay.template record.
So, I am thinking that I need to change the poll timeout for the
terminal I am trying to write to to "disable" poll reading from the
terminal.  I use seq records to sequence these read and write operations
and I could add at the beginning of the sequence a request to set the
timeout, to let's say 10 seconds, and at the end of the sequence restore
the original timeout.

Is the thread woken up when a new timeout value is written out to the
modbus module?
Is there a better way to make sure that the poll reads do not interfere
with the reading from and writing to the invisible registers?
Thanks Mark,
Zen

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System