High as You Can Go
Regarding higher-level languages [“Higher Ground — Part III,” Dec08, p52], the most important comment was by Kurt Williams from NI who said, “A language should encourage modular code development.” There is nothing more important than writing structured, modular code. But actual practice will be dictated by the talent of the programmer and time constraints.
Ladder logic is a very high-level language. I’ve seen simple machines controlled by a few dozen lines of ladder. Imagine the amount of C++ code it would take to write a timer and counter circuit. If you include the “timer timing” and “timer done” functions, and if you include error handling, it will be at least a couple dozen lines, probably more, if written in a terse style, and twice that if written in a verbose, understandable style.
It reminds me of the PC vs. PLC debate. The PLC is stronger than ever. Does anyone think that is just an odd fact? It is because the highly perfected real-time operating system combined with ladder or function or structured text is perfect for rapid application development of industrial controls.
Ladder is misunderstood and underrated. Do you really think all of us keep using it because we are ignorant or fearful? It’s widely used becasuse it’s the best tool for many industrial programs and is highly reusable. Another highly underappreciated fact is that the visual interface ladder logic offers for debugging and troubleshooting is sorely missed when you don’t have it.
C language is a preeminent tool, but that doesn’t mean it is a great fit for everything. Fortran had an object-oriented release in 2003 and a revision in 2008, and it is one of the most popular languages in high-performance computing. Most programs to benchmark and rank the world’s fastest supercomputers are written in Fortran.
Most of the complex projects we execute use a combination of ladder and structured text in the PLC and Visual Basic 6 in the HMI where we often open databases and flat files on the hard drive.
Ladder is not going away.
William Love, senior engineer,
Kredit Automation & Controls
More Motion Control Analysis
I saw your questions about the findings of your motion control Market Intelligence Report video in your Live Wire column [“Virtual Intelligence Tackles Motion,” Apr09, p15].
I am not surprised only 20% of respondents said they purchase integrated motors and drives. It is difficult to find people in the same group who will agree to use the same motors and drives. Usually the motors come under the mechanical vendor, and we end up with different motors and drives most of the time. Given the opportunity, I would prefer to have both motor and drive to be integrated.
Also, I believe we can improve or add features to the machine using software, but it is always limited by the mechanical limitations. Usually when I plan for these activities I try to maximize the software utilization.
Regarding the potential bottlenecks caused by faster speeds and increased capacity, if you are talking about semiconductor industries going smaller and faster, then it makes sense, but for the start and stop of a conveyor, my client would want me to forget about the speed and give him a consistent operation with a minimum of downtime.
We are using more and more EtherNet/IP and open standards. It’s become a must for the management to view the drive data. Having said that, it means, regardless of use, people ask for openness in the system. I totally support this. I see an importance for me to interface seamlessly with all my other third-party devices.
Arunkumar Srinivasulu
Project Engineer
LogiCamms
