Thanks for replying!
My IOC is running on a Red Hat Enterprise Linux 5 64-bit virtual machine
(VMware Workstation). My S7plc-EPICS driver came with the CODAC 2.0
control system for ITER (including the Control System Studio framework
and Self Description Data editor). So I can't say which version of the
S7plc-EPICS driver I am using - couldn't find any readme file in the
I experience the same problem of losing connection between the IOC and
the PLC every once in a while. But even if the connection is OK (the
CFGSTAT.val of the DTYP "S7plc stat" is "Connected") and the counter of
disconnections/reconnections is 0 - I still face the problem. Let alone
I have other PVs (digital inputs -states and binary outputs -commands)
that seem to be working OK. I even tried LONGIN record which worked.
Could it happen simply because we are using a Virtual Machine?
Pavel Maslov, MS
Efremov Institute / Pulsed Power Lab.
On Tue, Sep 27, 2011 at 2:36 PM, Marty Smith <firstname.lastname@example.org
We are using the EPICS ether_ip driver version 2.23 under EPICS R3.14.11
and are seeing the same thing when talking to a Allen Bradley
PLC. I have not had enough time to look into the problem deep enough yet
but every 20 minutes the data goes to zero and when that happens we are
experiencing a loss of network between the soft IOC and the PLC
The soft IOC is running on a linux-x86 64-bit virtual machine.
We see that this does not happen if we are running the soft IOC on
machine which is solaris but I don't have an explanation of why we
this same thing on both machines.
We would like to get to the bottom of this so I'm going to try to
look at the
problem during this week in more detail.
ANL / APS Controls Group
----- Original Message -----
From: "Pavel Masloff" <email@example.com
To: firstname.lastname@example.org <mailto:email@example.com>
Sent: Tuesday, September 27, 2011 1:04:16 AM
Subject: [S7plc EPICS driver] REAL type record jumps to zero
My name is Paul and I work as Control Engineer at the Efremov
Scientific Institute of Electro-physical Apparatus in St.
Petersburg, Russia. We are currently involved in the ITER project,
doing commutation switches for TF and PF superconducting coils. You
might have heard of the largest Tokamak reactor being built in the
south of France.
From the control standpoint we are proposed to use EPICS control
system and Siemens PLCs. Maybe you can help me for I have
experienced some problems gathering data from PLC in to EPICS. To be
specific, I collect REAL type data (electrical current) with a
discretization of 100 ms (PLC send-cycle) and 300 ms (EPICS
recvTimeout). Here is what I get in EPICS:
Instead of a smooth staircase-shape curve with, say, 100 ms
discretization (Fig. a) - my curve reaches zero periodically (Fig.
b). So it's the same staircase-shape curve, but when the value
changes, it becomes 0 beforehand. In other words, the last value is
not retained. It is as if pulsing: value-0-value-0-value-0-etc.
Maybe it can be better illustrated (see figures a and b, sorry for
the quality). So I guess, it is due to this 200 ms differential -
PLC sends data every 100 ms, EPICS receives data every 300 ms. Yet,
it's proposed the EPICS recvTimeout to be 2 to 5 times the send
intervall of the PLC. In my case it is 3.
1) Fig. a
2) Fig. b
0 ------ ------ ------
What do you think might be the problem? Can the last value be
retained by means of EPICS somehow. Because, from what I can see,
EPICS thinks it is nothing (0) when there is no signal, whereas I
need it to be at least the previous value to form a curve like on
I have observed (in CSS BOY) that while this zero-jump the FLOAT32
record was flashing READ_ALARM. This might be the case. But I have
no idea how to fix this.
• This is my db file:
field(INP, "@plc1_cfg/70 T=FLOAT32")
field(SCAN, "I/O Intr")
• Here is a line from the plcConfig.cfg file:
s7plcConfigure plc1_cfg, 172.20.92.1, 2000, 86, 2, 1, 300, 100,
"test REAL mode InWork 1"
• PLC communicates via Ethernet cyclically every 100 ms (OB35 :
It is interesting, though, that if I deal with data of other
type(longin or bi), then there is no such a problem.
Perhaps, the reason may lie within this data type itself (FLOAT32).
Maybe, I should have gotten it in WORD-type instead and process
afterwards. What do you think?
Thanks in advance and I look forward to hearing from you!
Pavel Maslov, MSc
R&D Institute for Electro-Physical Apparatus
Mobile: +7 (951) 672 22 19
Phone: +7 (812) 461 01 01