Source: Wikipedia
It is interesting, or maybe coincidental, that I had just left the National Instruments user conference about Graphical Programming (among other things) when I downloaded a Robert Scoble podcast interview with the principles of a new company who just launched a flow chart programming tool for high-tech programmers. (I couldn’t find a link for Scoble, but search Scobleizer on iTunes.)
The company has released No Flow JS and many companies had picked it up. A sample of the Flow Diagram Programming accompanies this post.
This brought back all the memories of flow-chart programming from the 90s. The only company still successfully pushing that paradigm to my knowledge is Opto 22. Phoenix Contact picked up the remnants of Think ‘n Do and Steeplechase many years ago. I can remember when the latter two companies thought that everyone would flock to their controllers because it was so much easier and more understandable to program in with flow charts than ladder diagram.
Unfortunately for them, engineers were afraid of the control platform–a PC. I told the CEOs for years that they should stop arguing in their ads about whose real-time operating system was better and concentrate on why engineers should switch from PLCs to the new platform. Meanwhile, Opto 22 found its niche and happily keeps customers happy with its controller and flow-chart programming.
NI uses a paradigm much like function block programming. I have programmed in LabView and recommend it over Ladder. On the other hand, I realize that there remain many thousands of technicians who are quite comfortable in Ladder. But even for those who love Structured Text, perhaps they should take a look at flow chart programming. If it’s coming to mainstream programming, could industrial be far behind?
Thanks for the kind words about Opto 22, Gary. We find that, while Opto’s flowchart-based programming software includes an optional C-like scripting language that’s popular with advanced programmers, most people who use it still structure overall program “flow” and logic visually with flowcharts.
David Hill
Opto 22
Gary, I’ve been engineering control system solutions using Opto 22’s Flow Charting methods since the early 90s. The very 1st project with that technology was a design-build system for a new compressor station and “Exchange Hub” facility being built by a major gas transmission company.
Additionally, the customer was beginning a process of choosing a standard programmable solution that would replace their legacy pneumatic and relay based station and compressor control systems throughout the pipeline. At that time they only had a few programmable analog loop controllers, and some configurable intelligent electronic devices (governors, electronic flow meters, etc.).
Additionally, they were in the middle of reorganizing their field support personnel; moving from a vertically disciplined organization to a multi-disciplined one. In fact all their gas measurement technicians, mechanics, communications technicians and corrosion technicians were already cross-training. With that in mind, pipeline management delegated the system choice for the new station to the technicians who would work there. The technicians were looking for a solution that would satisfy their various operational requirements and more importantly, one the technicians believed they could easily learn to use. You’ve probably guessed the outcome by now; it was in large part the Flow Chart programming method that eliminated the PLC alternatives of the day, and to a lesser extent the additional communications functionality of the PAC.
In summary, by ’97 those technicians had virtually re-automated every station and the associated reciprocating and gas turbine driven compressors between Texas and the West Coast with with their chosen solution. Surprisingly, of the various technician disciplines it was the mechanics took the lead and ultimately became “the best of the best” using it. And because of the simplicity of a “Flow Chart Paradigm”, by now those technicians have trained their younger replacements and fully retired by now.
Jim Bowman
CarolCon Enterprises
Gary,
To echo your thoughts, I am excited every day to hear about all of the new complex measurement and control systems that graphical, data-flow programming with LabVIEW enables because it makes the design of these systems more approachable. Especially as intelligence and I/O become more distributed, the efficiency gains of unifying around a central development environment for the all the system component is substantial and ever increasing.
With that said, depending on the engineering challenge it is important to select the right set of tools for the job including the need often times to incorporate existing code bases and expertise — that’s why it is important to have the flexibility and openness in a tool set so that the control engineer can reuse as much as possible whether that is C, C++, , or existing community built Linux applications in and alongside the data flow-based application.
Jonah Paul
National Instruments