For more answers to this question, click here.
A Control Design reader writes: We have some new younger engineers on staff who are fluent in some of the newer programming languages, but our customers want machines with more traditional programming languages like ladder logic. Are we wrong to hang onto International Electrotechnical Commission (IEC) 61131-3 languages? Upper management is slow to evolve with changing technology or letting the younger generation lead the way. Where are languages like Python and C++ most useful in industrial settings? Can Python run fast enough for real-time control? Where is the ability of C++ to create data logs most useful?
Answers
3 cheers for modular programming
The main push for ladder logic is that the people on the floor, troubleshooting the issues, may not know a higher-level language like C, C++, even structured text, or whatever. Companies don’t want to take the time to train everyone. But even ladder logic can be written in ASCII. “XIC My_tag” is a normally open contact with My_tag as a Boolean.
Regardless, the customer wants a higher level of ladder logic for easy-to-troubleshoot flow for when there is a problem on the floor.
Solution: Give them ladder logic on top, and use function blocks underneath that can be written in the format of choice. Also, write your code to be able to be troubleshoot from the human-machine interface (HMI) or an engineering station without the difficulty of “diving in.” Programmable logic controllers (PLCs) have the capacity to have modular code with good transitions so that you have inputs and outputs to functions.
Original equipment manufacturers (OEMs) do it with linear actuators, cameras and other components. Thus, the issue is not about ladder logic. It is about the time savings because ladders are easily read, and you can see the machine movement while it’s running.
Ignition is good at giving you a block that you can do a script in. This is the idea I’m talking about, but in the PLC. Mitsubishi Electric does it in GX Works3, in that you can have a structured-text function block. So, write the function in structured text and then stick it in your ladder. Who knew?
Here are three reasons to do this type of modular programming with different languages:
• Time: In some instance, it may save time to have repeatable code easily written off the PLC, but portable.
• Manpower: Having more than one programmer on a system and needing to interface with code.
• Function: It may be easier to interface with cameras, instruments or other computers in a non-ladder manner.
Is it wrong to hang onto IEC 61131-3 languages? Ha. IEC 61131-3 is the closest thing we have for standardizing PLC code. How can it be wrong?
It’s my belief data and machine learning will push us to interfacing with higher-level languages more. However, this is nothing new. We’ve been writing drivers for communications and doing extra things for vision. Real-time controls was C/C++ based at the point that we converted from Fortran and Adia. The idea in the manufacturing world—that this is new—is due to perspective. Aviation and space, missiles, boats and anything with a chip is familiar with higher-level languages being used in control. Some companies use a Level 2 control interface to do complex proportional–integral–derivative (PID) algorithms now and then drop data or signals to the Level 1 PLCs.
Your robots and motion controllers are not using ladder logic.
Python may not be fast enough, but this is hard for me to say, due to SciPy.
Tobey Strauch, independent principal industrial controls engineer, Fremont, California
Think of control, maintainability and support
We are not wrong to hang on to IEC 61131-3. The capability to upload from the controller and make some online changes is key. When SPEC executes a design-build of a process plant, we look at long-term maintainability.
A platform, such as CoDeSys, from a major automation manufacturer, ABB, Opto22 or a Siemens/Rockwell/Mitsubishi platform, delivered with the development system to a client will allow them control of their own system.
Our clients need to be able to call in a local rep or engineer from one of these companies and get support, which is not possible with one of these compiled languages.
Reading about Python and C++ reminds me of a client, back in 1999, which had iFix running and HMI with custom Visual Basic (VB) code. This VB code was using a non-Y2K-compliant comms library. The whole system needed to be re-developed, and I put the comms into the PLC code.
Regarding your other question on Python and C++, I can’t say C++ should never be used, but only if there is no IEC 61131 function to use.
Steven Landau, vice president—project development / SPEC Process Engineering & Construction, Tewksbury, Massachusetts
For more answers to this question, click here.
