Experimental Physics and
Industrial Control System

Di Maio Franck <[email protected]> · Tue, 27 Sep 2011 22:28:16 +0200

Dear Pavel

I think it is a communication issue.
We configure the PLC-EPICS communications to occur with a fixed period of 100 ms and a time-out of 300 ms but, except maybe with a fine-tuned system and network, it cannot be achieved 100 % of the time.

So the software need to cope with the case of PLC frames arriving "too late".
The approach that is implemented in the latest version of the CODAC Core System (v2.1.0) is to discard late frames and to treat the case as a minor error that doesn't invalidate the received data but generates a minor alarm. This was not the case in the previous version (v2.0.x). This is why you observe null values and errors.
Anyway, if no data is received after something like 10 times the time out, then it is a major error, anyway.

Ideally, we shall be able to choose between discarding late frames or storing them for processing them asynchronously in order to avoid missing any data change, but... (need time/resource to implement)

On the other hand, in an operational configuration, it should be possible to reach a predictable behaviour between well tuned IOC and PLCs on the same switch.

We are still investigating on what plays a role in this "flicker" and how to cope with it.
We'll try also tuning the EPICS computer (multi-core, RHEL). 

But I also wonder if others with similar requirements (predictable traffic with PLC) are using a dedicated network interface to separate the PLC traffic from CA.

Opinions?

Franck

-----
From: Pavel Masloff [mailto:[email protected]] 
Sent: 27 September 2011 08:04
To: [email protected]
Subject: [S7plc EPICS driver] REAL type record jumps to zero

Hello guys!

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
+
+                                   -----------
+                        -----------    
+             -----------
+  -----------
+                                  
+                                                  
+
0+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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 Fig. a.
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:

record (ai,"TEST-FDU-COMM:I_VCB")
{
    field(PINI, "YES")
    field(DTYP, "S7plc")
    field(INP, "@plc1_cfg/70 T=FLOAT32")
    field(SCAN, "I/O Intr")
    field(TSE, "-2")
    field(EGU, "Amps")
    field(PREC, "2")
    field(HIHI, "80000")
    field(HHSV, "MAJOR")
    field(HIGH, "70000")
    field(HSV, "MINOR")
    field(LOLO, "0")
    field(LLSV, "NO_ALARM")
    field(LOW, "2500")
    field(LSV, "MINOR")
}

. 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  :  Cyclic 100ms)

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!

-- 
Sincerely,

Pavel Maslov, MSc
R&D Institute for Electro-Physical Apparatus

Mobile: +7 (951) 672 22 19
Phone: +7 (812) 461 01 01

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System