Automation Portals
- Automatic Identification
- Design & Simulation
- Digital Factory
- Electrical & Control Panels
- Embedded Automation
- Factory Automation
- Fieldbus Networks
- Flow, Level & Process Inst.
- Fluid Power, Valves & Pumps
- HMI & Operator Interfaces
- Industrial Communications
- Industrial Computers
- Industrial I/O
- Machine Control
- Machine Safety
- Manufacturing Intelligence
- Motion Control
- OPC
- Plant Management & Maint.
- PLCopen
- Process Control
- Process Safety
- Programmable Controllers
- Robots & Robot Controllers
- SCADA & RTU
- Security
- Sensors
- Systems Integration
- Test, Measurement & LIMS
- Vision
- Wireless Connectivity
- Network Portals
- EtherCAT
- EtherNet/IP
- PROFINET
- Industry Portals
- Building Automation
- Chemical
- Food & Beverage
- Machine Tools, CNC & DNC
- Material Handling
- Oil & Gas
- Packaging
- Pharmaceutical
- Power & Energy
- Transportation (Microsite)
- Water & Wastewater
- Event Portals
- Hannover Messe
- ISA Automation Week
Databases The Perfect Complement to PLCs
By Steve Hechtman, President, Inductive Automation
PLCs? Okay, youve tackled PLCs and now you can program em with one hand behind your back. So whats next? Whats the next logical challenge? Think SQL and relational databases. Why? Youd be amazed the similarity. Its the next logical progression.
You might ask how it is theyre even related. For one thing, relational databases can sort of be an extension of PLC memory. Live values can be mirrored there bi-directionally. Historical values and events can be recorded there as well. But operators and managers can interact with them too. Its been over twenty years of working, living, breathing and thinking PLCs, but over the last six years Ive delved heavily into SQL and learned a lot about relational databases. Ive discovered that working with SQL is remarkably similar to working with PLCs and ladder logic.
SQL has four basic commands and about a hundred different modifiers that can be applied to each. These can be applied in various ways to achieve all types of results. Heres an example. Imagine effluent from a wastewater plant with its flow, PH and other things being monitored and logged. Thats what you typically see. But now lets associate other things with these, such as, discrete lab results, the name of the persons who did the lab work, the lab equipment IDs and calibration expiration dates, who was on shift at the time and the shift just prior, what their certification levels were, what chemicals where added and when, who the chemical suppliers were, how long the chemicals sat before use, and so forth ad infinitum. All of this becomes relational data, meaning that if its arranged properly in tables you can run SQL queries to obtain all types of interesting results. You might get insight into the most likely conditions which could result in an improper discharge so it can be prevented in the future.
In my explorations of SQL, I found myself looking at the layout of my tables and evaluating the pros and cons of each layout. I massaged them, turned them on their side, upside-down, and finally ended up with the most appropriate arrangement for my application. And similar to PLC programming, I explored innumerable what-if scenarios. I was struck by the amazing similarity in my approach to developing solutions for PLCs. This has been a lot of fun in fact exhilarating just like PLCs used to be. Its the next logical progression you know.
SQL is a high level language that isnt very hard to learn and you can be very clever with it. I prefer to think of it as a natural extension to my PLC programming skills. Now that you have the machinery running, what did it do? Furthermore, relational databases and SQL pull people and processes together. Machines dont run alone. Theyre merely part of a containing process and that process was devised by people. SQL and relational databases form the bridge to integrate processes, machinery and people together. I dont believe a COTS (commercial-off-the-shelf) package can do it any more than you could offer a COTS palletizer program and have it be of any use. It just doesnt work that way. Every machine is different. And every business process is different. Thats where the SQL comes in. It has to duplicate or augment existing process flows and these are intimately connected to the machinery. And thats why the PLC programmer is best suited to implement solutions involving PLCs and relational databases.
So where do you start? I would suggest picking up a book at the bookstore like one of those dummies books. Then download and install the open-source MySQL database server along with the MySQL Administrator and Query Browser. It only takes a few minutes to install and then start playing. You can read about a LEFT JOIN or INNER JOIN but typing one in and observing the results is worth about 1000 words. At the end of an evening youll probably be very excited with all of your new found knowledge and be thinking of endless ways to employ it in your own field of practice. Happy SQLing!
Please click here to access the Inductive Automation website for more information: www.inductiveautomation.com/
PLCs? Okay, youve tackled PLCs and now you can program em with one hand behind your back. So whats next? Whats the next logical challenge? Think SQL and relational databases. Why? Youd be amazed the similarity. Its the next logical progression.
You might ask how it is theyre even related. For one thing, relational databases can sort of be an extension of PLC memory. Live values can be mirrored there bi-directionally. Historical values and events can be recorded there as well. But operators and managers can interact with them too. Its been over twenty years of working, living, breathing and thinking PLCs, but over the last six years Ive delved heavily into SQL and learned a lot about relational databases. Ive discovered that working with SQL is remarkably similar to working with PLCs and ladder logic.
SQL has four basic commands and about a hundred different modifiers that can be applied to each. These can be applied in various ways to achieve all types of results. Heres an example. Imagine effluent from a wastewater plant with its flow, PH and other things being monitored and logged. Thats what you typically see. But now lets associate other things with these, such as, discrete lab results, the name of the persons who did the lab work, the lab equipment IDs and calibration expiration dates, who was on shift at the time and the shift just prior, what their certification levels were, what chemicals where added and when, who the chemical suppliers were, how long the chemicals sat before use, and so forth ad infinitum. All of this becomes relational data, meaning that if its arranged properly in tables you can run SQL queries to obtain all types of interesting results. You might get insight into the most likely conditions which could result in an improper discharge so it can be prevented in the future.
In my explorations of SQL, I found myself looking at the layout of my tables and evaluating the pros and cons of each layout. I massaged them, turned them on their side, upside-down, and finally ended up with the most appropriate arrangement for my application. And similar to PLC programming, I explored innumerable what-if scenarios. I was struck by the amazing similarity in my approach to developing solutions for PLCs. This has been a lot of fun in fact exhilarating just like PLCs used to be. Its the next logical progression you know.
SQL is a high level language that isnt very hard to learn and you can be very clever with it. I prefer to think of it as a natural extension to my PLC programming skills. Now that you have the machinery running, what did it do? Furthermore, relational databases and SQL pull people and processes together. Machines dont run alone. Theyre merely part of a containing process and that process was devised by people. SQL and relational databases form the bridge to integrate processes, machinery and people together. I dont believe a COTS (commercial-off-the-shelf) package can do it any more than you could offer a COTS palletizer program and have it be of any use. It just doesnt work that way. Every machine is different. And every business process is different. Thats where the SQL comes in. It has to duplicate or augment existing process flows and these are intimately connected to the machinery. And thats why the PLC programmer is best suited to implement solutions involving PLCs and relational databases.
So where do you start? I would suggest picking up a book at the bookstore like one of those dummies books. Then download and install the open-source MySQL database server along with the MySQL Administrator and Query Browser. It only takes a few minutes to install and then start playing. You can read about a LEFT JOIN or INNER JOIN but typing one in and observing the results is worth about 1000 words. At the end of an evening youll probably be very excited with all of your new found knowledge and be thinking of endless ways to employ it in your own field of practice. Happy SQLing!
Please click here to access the Inductive Automation website for more information: www.inductiveautomation.com/