This is English version of the my publication, which was publicated here.
Good day, reader.
After a long break, I decided to share a description of a recent development that could be useful in the industry.
I developed a prototype runtime (execution environment) for a motor manager—a microprocessor-based device (MP device) for controlling and protecting electric motors.
For those who may not know, a runtime is a program (or a set of programs) that runs on an MP device and turns it into an industrial PLC or a relay protection and automation device.
First and foremost, the runtime enables the execution of logic written by engineers using languages from the 61131-3 standard. For example, LD (Ladder Diagram) for relay-contact logic, FBD (Function Block Diagram), and so on. It is the runtime that "digests" the 61131-3 logic and ensures the operation of timers, processing of PLC inputs and outputs, various numerical operations, and much more.
In this runtime prototype, I aimed to implement logic that would be fully compatible with the Schneider Electric Tesys T device.
Tesys T is an MP device that is widely used in Russia (and globally) in industrial settings for motor control and protection. Unfortunately, there is no adequate replacement for this device on the Russian market.
In Tesys T, an IL-like (Instruction List) language is used for logic, and I fully implemented this set of commands in my runtime.
The idea was to allow seamless migration of logic from Tesys T to my developed runtime, ensuring that Modbus addresses fully match those of Tesys, which is crucial for SCADA systems.
This is in case someone decides to deploy my runtime on their MP devices as a motor manager, replacing the Schneider Electric Tesys T.
The good thing is that since I am developing this myself, I am not limited to just Tesys commands.
I recently discussed this with a colleague, and he pointed out that Tesys logic lacks commands for bitwise XOR and TOF (Turn-Off Delay) timers.
I immediately implemented and tested these XOR and TOF commands.
In summary, the runtime is now fully compatible with Tesys logic while also offering an enhanced set of additional commands.
Currently, the runtime can execute the entire set of Tesys commands, plus extra command blocks that I thought would be useful to have.
It is written in C++.
Later, I recompiled it to support the AARCH64 processor architecture, allowing it to run on a Raspberry Pi 4.
The runtime has a built-in Modbus server and handles Modbus server registers.
At the moment, temporary registers in the logic correspond to the INPUT REGISTER of the Modbus server. They are accessible from an external client and are read-only.
Regular registers correspond to the HOLDING REGISTER in the Modbus server. An external client can both read and write values to these registers.
Additionally, the runtime can control GPIO on the Raspberry Pi.
For now, I have mapped output relays to a holding register with address 0 and its bits.
Each bit of the zero register corresponds to an output relay. This is clearly visible in the video below.
The logic executes quite quickly on the Raspberry Pi. If the artificial delay is removed, the runtime processes a 23-line logic block in an average of 5 microseconds per cycle.
For now, I load the logic using a simple text file.
It looks like this.
By the way, my runtime can accept logic with comments!
The FBD logic diagram to make it clearer what we are trying to implement.
The purpose of this logic diagram is to start a pulsating bit (LifeBit) scheme via a Modbus command.
By the way, I added some of my own commands to the logic that are not present in Tesys, as you may have noticed:
SET_IF_BIT
This is the execution of an operation only if there is a control bit. A kind of bit multiplexer.
Watch the video where the runtime is running on a Raspberry Pi 4, controlling Modbus registers, GPIO, and output relays.
In the video, I send commands over the network via Modbus poll:
1) By setting the value 1 in register 5, the pulsating bit scheme is started, which affects the GPIO output relays.
2) By setting the value 0 in register 5 (setting the zero bit to 0), the pulsating bit scheme is stopped.
3) Register number 0, its bits control the output relays. By writing 1 and 0 to these bits, we set the output relays to the triggered or non-triggered state.
4) The video has no sound, but you can clearly hear the relays clicking. You can connect an external 220 VAC load, such as a lamp, a small load (optimally up to 5 amps, although the relays are rated for 10 amps, I think they would get quite hot at that current), or a contactor if the load is large.
5) Pay attention to registers 1 and 3 in the second Mbpoll2 window. This is where the countdown timers are triggered. The timers for the pulsating bit count down in 100-millisecond intervals, with a setting of 10 * 100 = 1 second.
The runtime can be run on a regular computer, where GPIO will not be available, but you can control and monitor Modbus registers.
In terms of logic, this is already a fully functional prototype, and there are plans to further develop it.
It is possible to add motor control and protection modules (similar to Tesys).
The ability to save oscillograms. This is a separate big topic.
The ability to log events, including the creation of manual triggers from the logic.
Potential applications:
1. In embedded devices. Ideally, this would be a replacement for the Schneider Tesys device.
2. Another interesting application for the runtime is as a virtual motor manager.
The idea is that in reality, a single substation may have hundreds of MP motor manager devices.
Instead of these hundreds of devices, there would be two high-performance servers—primary and backup—running these hundreds of MP devices. With the same logic, settings, and control as real motor managers, but virtual.
However, they would also control output relays in groups, compactly located in one cabinet, and receive analog and discrete signals from cells, either digitally or via ADC.
The advantages I see in this approach:
1. No moving contacts for Ethernet cables that need to be routed to the device. Those who have dealt with this know that it is a real headache in substations. These moving contact connectors for communication often fail, disrupting communication, which is critical for SCADA and production.
2. The network infrastructure would be reduced by an order of magnitude—no need for numerous switches and routers that support a large number of devices.
3. Servers are quite robust devices, and with redundancy, it is possible that this would be more reliable than a single ordinary motor control device.
4. A virtual motor manager does not require replacement or maintenance—except for the server itself, which replaces hundreds of units.
5. In terms of information security, a server is easier to protect than hundreds of distributed devices. Again, even by reducing the amount of network equipment.
There are probably also some disadvantages. Here are a few off the top of my head:
1. Long control cable lengths.
2. Equipment would be required for converting and transmitting analog and discrete signals.
3. Running the runtime as a digital twin—a copy of a real device—with the possibility of use in digital models of production processes for forecasting, etc.
If anyone is interested in this article or topic—please leave a comment, feedback, or contact me directly on Telegram @antonovgp
Read the next chapter of this history here.