IEC 61131-3 is the de facto standard in the industrial automation industry. It encompasses 5 different programming “languages”. It makes designing simple programs straightforward and easy, and it does this very well.
General Purpose Programming Languages Are the Future for the Industrial Automation Industry and Are Overtaking Traditional PLC IEC 61131-3
Stefan Reichenstein | Robotic Systems Integration
However, where it lacks is designing complex systems. Using a general purpose programming language to program motion applications allows a user to integrate many different sources of information that would otherwise be difficult or impossible. It allows you to scale a system up or down as desired. You could design a part inspection system running its own computer vision algorithms, to a hyper converged system running multiple of those inspection systems while communicating with a database keeping track of inventory and parts.
With the RapidCode API being written in C++, you are able to run it on standard off-the-shelf computing hardware directly in Windows, or with remote procedure calls on any system that can run gRPC. As such you can design a system however you want. It can interface with vision systems, analytics, databases, other systems, and a local network.
Because the RapidCode API is a C++ API, we are able to use SWIG to generate interfaces files to call the C++ API from whatever language SWIG supports. The generated interface files load the RapidCode dll and pass function calls from your language of choice to the C++ dll. At the moment we support C++, C#, and Python, but this list is always changing, so reach out if you have a language request.
In addition to our C++ and SWIG generated APIs, we provide a gRPC server that can run on either Windows or the INtime RTOS and its complimentary Protocol Buffer interface, RapidCodeRemote. While gRPC is well suited for microservices, we leverage the remote procedure call aspect of gRPC. Our gRPC server represents a single motion controller, which a client can connect to to directly call motion commands to program their applications. Because we provide the protocol buffer interface, you can generate client code in any language supported by Protocol Buffers. Google currently provides first party support for C++, Java, Go, Ruby, C#, and Python with third-party implementations for C, Haskell, Perl, Rust, amongst many others (https://github.com/protocolbuffers/protobuf/blob/main/docs/third_party.md).
As more students learn to code they are learning modern and general programming languages and practices. As of October 2022 the top 5 languages with approximate “market” share are Python (17%), C, (15%), Java (13%), C++ (10%), C# (4%). With the exception of C, these are all “modern” object-oriented languages. With competent programmers, the language is irrelevant, but by designing your motion applications using modern practices (which are often enabled by modern languages), developers will be able to hit the ground running. Instead of new programming taking additional time to learn any of the 5 IEC 61131-3 languages (Ladder Diagram (LD), Sequential Block Diagram (SBD), Structured Text (ST), Instruction List (IL), Sequential Function Chart(SFC)) they can spend more time learning the design of the systems they are working on.
A huge advantage of using any of these modern languages is that there are incredibly powerful Integrated Development Environments (IDEs) to program in. Whether you are using Microsoft’s Visual Studio (quickstart) or VS Code, Jet Brain’s IntelliJ, these IDEs allow you to quickly see syntax errors, autocomplete available functions and classes, view documentation, analyze and identify common patterns and errors, refactor functions and classes, design and execute tests, and track changes in source control, as well as the expected setting of breakpoints, and inspecting of variables.
Each of these features help programmers develop bug free code. As systems and software gets larger and more complex, this becomes increasingly important to reduce time spent debugging and tracking down bugs and identifying issues that will inevitably arise.
As the adage goes, “hardware is hard”. It is straightforward to design a simple PLC, but as the complexity of a system grows, increasing the functionality of the PLC and adding additional ones becomes increasingly difficult. Communication is now something that needs to be considered. Bugs become increasingly difficult to pin down. Making changes after production is impossible without physically getting hands on the system in question. Production requires specific components, which if you have supply chain issues like we are currently having (circa 2022), can prosent massive logistical problems.
Software is not necessarily easier and certainly not a panacea, but programming motion controls using modern PC languages eliminates these issues on at least this one aspect of a system.
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Comments (0)
This post does not have any comments. Be the first to leave a comment below.
Featured Product
