🥇OVEN PLC110[M02]-MS4, HMI, OPC and SCADA, or how much chamomile tea a person needs. Part 1

Good day, dear readers of this article. I'm writing this in review format

A small warningI want to caution that if you immediately understood what this is about from the title, I advise you to change the first point (the PLC core itself) to anything from the next pricing tier up.
No savings are worth such a level of stress, subjectively.

For those who are not intimidated by a bit of gray hair and an amplitude of nervous ticks, later I will describe in detail how this technological marvel was created. In this article, however, there is a brief analysis of the project with a certain degree of criticism.

Inception. Task Setting

So, I work at an engineering bureau, and we are testing automation equipment for integration into our turnkey factories. Recently, equipment from OVEN arrived at the warehouse, and it was decided to assemble a test stand from it:

PLC110[M02]-MS4 (execution environment MasterSCADA 4D)
Operator panel SP307
Universal analog signal input module MV110-224.2A
Signal input module for strain gauges MV110-4TD
Electrical measuring module MV110-220.3M

System Structure was chosen with network segregation by purpose:

Modbus RTU based on RS-485 — communication between PLC and subordinate devices (modules, frequency drives, intelligent sensors, HMI panel SP307), PLC-master of the network.
Modbus TCP based on Ethernet — communication between different PLCs and with the OPC server
PC-server OPC and SCADA systems simultaneously act as a gateway between two different networks (Corporate LAN of the enterprise and Modbus TCP network of controllers (two network adapters with data routing using standard Windows tools)
Corporate LAN has access to the internet via a proxy server

The overall system structure is presented in the image below:

Embedded functionality

Collection and redirection of data from PLC to OPC server
Local control and monitoring via HMI panel
Control and monitoring from SCADA through OPC server
Control from any PC within the enterprise LAN and through the internet using SCADA client
Connection of mobile OPC monitors via LAN and internet
Naturally, archiving and report generation

It seems we haven't overlooked anything. We have a general description of the system, and now, actually, on the topic (I will describe the ways of troubleshooting in articles with the implementation of each node):

Emerging difficulties

1. Documentation for PLC

The beta testing of the claimed PLC based on the MasterSCADA 4D core was announced by the manufacturer in 2012. Despite such an impressive duration of the concept's existence, what the developer has in 2019 is just a programming guide of 28(!?) pages, which contains almost no useful information, and the screenshots in the manual are from MasterSCADA 3D, which is quite amusing considering the interface has changed.

Additionally, there is active support from three advocates and a sales manager on a forum thread containing 20 topics.

2. PLC Architecture Modules

This is a separate topic for discussion. In brief: the PLC communicates with the modules as Modbus RTU slave devices, which must first be configured using a utility by separately connecting each one to a PC via an RS-485 converter.

Smart folks can surely do this without a converter through the PLC by connecting the modules in series on the network and writing the necessary registers, but that comes with experience and a lot of pain.

For a developer seeing such an architecture for the first time, it is not user-friendly at all.
Also, all analog modules tend to fail for unknown reasons, taking the entire RS-485 network into Terra Incognita, but I want to discuss this separately; it’s quite an epic, indeed. This issue has been around for about 10 years, and the manufacturer plays it off. ‘We must admit, the templates did not work out’, however, this is the only interface for communicating with the modules, and people have been seriously writing their implementations of Modbus RTU for a long time.

Meanwhile, the chamomile tea was coming to an end… The sun was setting

3. IDE MasterSCADA

I won’t talk about the graphic tools; I haven’t tested them much, but I’ll say right away that I didn’t like them.

Let's talk about implementing data exchange and the IEC standard languages:

The physical inputs and outputs of the controller are not global variables and cannot be accessed from any part of the program by writing an alias, like ‘DI1’. Each program must drag this manually; a local variable is formed, which inherits or passes the value. That is, the very essence of the PLC, in my view, is somewhat lost: the device should simplify the programming of the logic for physical channels to the level of ‘If input DI1 is triggered, turn on output DO1’, and it looks like this "Input DI1 — Variable LI1 — Variable LO1-Output DO1", also due to the ignorance of this principle in the IDE, you might encounter the delightful warning "Boolean-Boolean conversion is impossible" (most likely, one of them is a pointer, but I imagine in the editors of the creators, it looks more harmonious).

The libraries for the ST, FBD, and SFC languages are quite extensive and offer a variety of programming conveniences; however, these components are not functions, but classes, within which methods are embedded, and most of them lack documentation describing functionality and data types. My persistence led me to the core CodeSys libraries, from where these functions were taken, and their documentation was helpful.

4. Communication with the SP307 panel

A rather interesting event for those who have a couple of days to spend.

Standard GUI (HMI or SCADA) testing for me means running 6 trials:

Reading a discrete signal
Writing a discrete signal
Reading an integer value
Writing an integer value
Reading a floating-point value
Writing a floating-point value

Accordingly, I draw 6 primitive components on the screen and check each in order.
The communication is absolutely the same as with the modules, but from a separate PLC RS-232/485 port, and seems to be more stable. Since it is an HMI slave, I wrote to it on change and polled every 500ms to avoid missing the operator's actions.

The first 4 points were executed excellently, but points 5 and 6 caused problems.

We send Single Float type data, display it on the screen and find that the data is incorrect, even though all the output settings (Float, 1 register dimensionality, etc.) are correct. It would be untrue to say that there is no precedent described in the documentation, however, good luck finding which one and where; it's amusing from the outside.

After frantically going through all the settings related to the data and its transmission, we write to technical support, the response takes on average 5-6 calendar days; we follow the standard tech support script "Check that the power is on — check the firmware version — please wait another week – We will figure it out ourselves"..

By the way, it was resolved by enabling a checkbox in an absolutely inappropriate location with an absolutely inappropriate label.

The functionality of the screen does not accommodate the input of an analog signal in the format "Slider"., you can only enter numbers in the text field. It’s simply amazing, either we use the buttons “±” and script it ourselves or we enter the number using the keyboard, forgetting about soft control of any drive.

I won’t overload the article too much, so I will describe the issues with the top level in part 2.

In summary, I want to note that I had enough freedom and a lot of time to tackle these problems, which at first glance seem trivial, but cause a lot of pain for the affected party. Facing such issues under tight deadlines is critical.

P.S.: All the points made here are subjective and are merely an attempt to warn the unprepared rather than discriminate against manufacturers. Please consider this article from that perspective.

Part two is already here: click

Source: habr.com