PLK210

About the features of programming OWEN controllers based on IDE Codesys 3.5

Quote from the OWEN forum – "CODESYS V3.5 is a fairly complex software product, and quite often users have questions about working with it."

Is everything so unclear and complicated? We're trying to figure it out together.

 

The purpose of the article: to share my experience with this product, to help new users avoid stepping on those "rakes" that I myself stepped on. I will give below useful tips for setting up. Maybe it will save someone some time.

I have passed more than 30 different objects on SPK107, PLK200, PLK210 and I can already form some kind of subjective, but judgment based on personal experience of implementing PLC data.
If you do not agree with any theses, leave a comment at the bottom of the page, I will definitely publish it.

How powerful these controllers are and what they are suitable for (private and subjective opinion):
SPK107 (M01) is well suited according to its data for the implementation of a small automation system consisting of approximately five to six supply and exhaust systems. This is approximately 15 I/O modules with 8 channels each. With the recording of violations in the accident log and process trends, with the output of data to the OwenCloud cloud. I do not advise loading more, since the panel will start behaving less predictably when the processor and memory are loaded above 70%. I do not advise loading complex graphics or a large number of high-speed algorithms. You will encounter process freezes or interface failures.

PLK200 (M02) is well suited for medium-sized automation systems (thermal points, etc.) with up to 20 I/O modules. You can hang more modules, but with this amount, the CPU load was already up to 100% (the DELTA DOP-110WS visualization panel was suspended by OPC UA). The web interface in my case did not pass, I had to delete it. I fought for the optimization of the controller and removed all the "superfluous".
In the future, I had to abandon OPC UA and the CPU load returned to normal.

PLK210 (M02) is seen as the best of the entire line due to the characteristics of memory and processor. It is well suited for systems with a capacity of up to 40 I/O modules. I handed over quite large systems on them, with a large composition of PID regulators and other rather branchy logic. 

It is important to note that until the end of 2023, this direction had a very dynamic growth. Controller firmware, Codesys 3.5 service packs were changed approximately twice a year, which led to an increase in labor costs. Old problems went away, new ones came.

In my opinion, frequent firmware changes and / or frequent platform changes do not lead to the success of the integrator, rather, on the contrary. With each new version, you begin to struggle with the unknown, because you don't know about the surprises that are embedded in the equipment you bought. There are always risks that any new problems will emerge and it will be impossible to rely on previously accumulated experience.

The above controllers are created on the basis of a pre-installed Linux operating system with a Realtime OS add-in. If you are not an active developer and / or a person who understands the core of this system well, then I assume that you will definitely find difficulties in working with these devices.

Tip: to develop programs for these types of controllers, you need to reserve a little more development time than you expect. It will be necessary to debug not only the program that is related to the process technology, but also the controller itself. Moreover, it is important to note that the controller compiler will weed out only the simplest programmer errors, allowing you to load the PLC with a number of rather unpleasant errors.
The result of loading these errors may be a sudden shutdown of the controller (switching to EXCEPTION mode). This is a mode in which the PLC seems to work according to external manifestations, but in fact it is stopped or behaves as stopped.

Below are the common errors/features in working with PLC data that can lead to switching to EXCEPTION mode:

1. Emergency messages without restrictions
 
You have decided to use the alarm message output in the Codesys system tables. Then do not forget to set a limit. Without limits, memory is used unpredictably for the user.

2. Use only those libraries in the project that you really need.


 
In pursuit of typing a solution, I often simply copied my own project from the previous commissioned object and slightly adjusted it to new targets and new conditions. This approach is good organizationally (saves time), but also carries the risks of dragging unused libraries into the project. To avoid call errors, unused libraries had to be deleted. Every time the customer asks to supplement the project with some new function like recording accidents on a flash drive – do not rush to do it. Debugging the entire system with this new feature can go completely according to a bad scenario if the project was no longer small.

3. The OWEN cloud.
Using the Owencloud interface in a project, if you don't actually use it, continues to "eat" memory, take up processor resources.


  
The Owencloud topic itself must be disabled via the option in the properties.


 
The task of calling Owencloud should be excluded from compilation.

4. Task Manager. Try to set such cycle values for tasks so that the minimum jitter value does not exceed 10000, the maximum cycle time of each task would not exceed the set value. Do not be afraid to set the visualization tasks to values up to 800 ms, observing, of course, the reaction of the operators.
 


5. In the web configurator there is an option to reboot by exception, but I do not advise you to hope for this - unfortunately, it does not work (I tried it with PLK200). There was a case when the object got up and had to leave urgently to find the reasons with this option set. It is easier to catch the controller shutdown by some third-party means (a flashing lamp from DO, a ticking control indicator, a third-party PLC capable of restarting your controller relay if there is no data increment on the diagnostic tag).


 
This does not work in practice, I do not advise you to believe.

6. Use the Debug option and "leaking descriptors"
 


The lower field, if it has a value of more than 100, indicates a "leak of descriptors" or an uncontrolled increase in the number of text files associated with the operating system. When this value reaches 1024, the controller predictably enters EXCEPTION mode. In my case, the PLK210 had Web visualization and the operators were left without screens (everything went out).



This is what a "Descriptor Leak" looks like


7. Controller log

  

Unfortunately, the log may not give an unambiguous answer about the problem that has arisen, but indirectly it can be understood that there are problems with accessing the controller's memory + there are problems with communication between the Delta panel using the OPC UA protocol (the default password was set in the panel). Messages can be of huge importance if not cleaned and opened for the first time.

8. Communication error with I/O modules
It is solved by installing the gateway address in each module and in the PLC (for modules, logically, this is the PLC address; for the PLC, if there is no router in the network segment, you can specify the address of the nearest module), by setting a check mark (flag). You need to set the "Auto-connect" option in the wizard settings, and the socket timeout is 50 ms.

9. Target visualization
Quite an important mistake. Occurs when you previously developed a project for SPK107, and then converted it (changing the target file) for use with PLK200 or PLK210. As a result, the target visualization remains as a non-working vestige and spoils the operation of the controller. It's hard to understand right away.


 
It is noticeable by this error
10. Symbolic configuration.
If a symbolic configuration is added, but not a single parameter is selected, then most likely this will lead to a descriptor leak, since the OwenCloud node always implicitly uses the symbolic configuration (a well-known situation that OWEN plans to correct in firmware 3.x).

11. Log files
To upload files, you need to connect to the PLC via WinSCP (root/owen), in the /root/CODESYS folder, in addition to the main PlcLog.csv file, there are most likely other files of the following type PlcLog_x.csv. It must be remembered that this should be done immediately after the event. In a day, this information will be reused. Pumped out these files. There is information for a maximum of two days, no other history is saved.

12. An extremely important mistake of the developer is the use of global variables in the symbolic configuration, where simultaneous read and write operations occur. I had a "bad habit" of putting all the variables for both scada (HMI) and polling I/O modules into one section. It was both easier and faster to do, but you CAN't do that!!! 
You need to create separate sections for variables. Try to assign read and/or write permissions to all variables.
 
The arrow "from us" is the "read-only" arrow on the HMI side, in the opposite direction "write-only", back and forth "read and write".



The latter should be minimized

13. Auto-save projects


 
Sometimes it also happened that all the day's work turns into zero. It's just that the antivirus didn't like the activity inside the Codesys project file and it reset all the bytes of the program, of course, including the backup file. This is tin. I had to redo everything from memory. Save even more often, with downloading the result. Remote work has such risks.

14. Features of setting up the DELTA control panel by OPC UA.
In the DELTA panel, "address" and "password" are set by default. By default, the PLC uses an anonymous OPC UA login, without any protection. In addition, it is not clear what the check mark (flag) "Optimize" in the Delta panel means.

15. By memory wear: each creation of a bootable project is executed in Flash memory and, accordingly, consumes a resource. When 100% is reached, there is a chance of getting an exception and stopping the project if the program cannot get data from any memory block (due to its wear and tear).

16. Two Ethernet ports in bridge mode at PLK200.
It is highly not recommended to combine the ports on the PLC 200 into a bridge, as this leads to a critical load on the processor, which is why this option was removed from the network setup wizard. If necessary, configure port forwarding or static routes.

https://ftp.owen.ru/CoDeSys3/99_ForumFiles/Plc210_PortForwarding.pdf

https://ftp.owen.ru/CoDeSys3/99_ForumFiles/Plc2xx_StaticRoutes.pdf




Debugging projects is an important milestone when working with OWEN controllers, you will need coffee and crutches and probably a bike and a lot of peace of mind.
Keep this in mind when setting time deltas for developing your solutions

#Debugging, #OWEN, #Codesys3.5, #PLK210, #PLK200, #SPK107