FactorySQL brought magic to the plant floor. It would have been called "Yesware" except that name was already taken. This is because you could say "yes, I can do that" to practically any PLC to SQL database interaction you could imagine.
Want to log PLC values? No problem. Want to send recipes to PLCs? Go for it. Want to mirror PLC addresses in the SQL database so that web pages can display and control PLC values? Go for it. Want to copy whole sections of PLC memory to another PLC somewhere else. Yes you can. In fact, the possibilities are endless but they boil down to being able to say "yes, I can do that" while everyone else is shaking their heads "no."
I've had two integrators sit beside me on a major project where all they ever said was "I'm not sure how we'd go about that" and all I ever said was "don't worry, we'll take care of it," and then we would, usually in minimal time. The other integrators looked kind of dumbfounded because I kept doing this. But my secret was FactorySQL.
Well, now we have Ignition and under the hood we still have FactorySQL but it's no longer called that. Now we call it the SQL Bridge Module. But it does all the same things and more. For example, you can make programming changes while groups are running without interrupting anything, just like online programming changes in a PLC.
I fear one thing though. With all the excitement about the Ignition platform I'm afraid we're neglecting to tell people about the real power they have under the hood with the SQL Bridge Module. The other day when one of the sales people showed it to someone they were blown away by what they saw - they could hardly believe what they were seeing was true.
So my message to you... check it out. You'll be amazed at what you can do.
Intro
This blog is dedicated to open, interoperable manufacturing software and the coolest, latest and greatest things I see every day while conducting business under the banner of Inductive Automation.
Hello, my name is Steve Hechtman and I am president of Inductive Automation. During the span of one day there is more excitement, more discovery than I can possibly keep to myself. This blog is, therefore, my outlet. WARNING: This site is highly biased in favor of the most powerful, affordable manufacturing software in the world - Ignition by Inductive Automation!
FactorySQL Under the Hood
Does OEE really work?
You've heard about OEE for years now. But does it really work? I've got a story for you but first I'd like to comment that OEE is just a tool. You can either use it, abuse it or neglect it.
Some months ago one of our end-users installed the OEE module at one of their facilities that has a lot of lines. A lot of data has been collected but only recently did the production manager started analyzing it. His attention was drawn to one machine on one line by reason of the OEE. On closer inspection he determined the machine was pausing at times for no apparent reason so he called in maintenance. It's not unusual for automated machinery to slow down or pause due to low product supply or backup conditions but this just didn't seem right. By monitoring the PLC logic maintenance was able to trace the problem to an intermittent field IO block that sometimes gave false state information for some photoeyes.
After the part was replaced the OEE jumped up by 10%. They had accumulated a baseline of OEE information and just by replacing this one part the OEE increased dramatically. In this case the faulty component didn't entirely stop production so its effects weren't obvious. It just made the line not run as well as it could.
This brings me back to the main point. For OEE to work it has to be properly implemented and then the resultant data need to be acted upon. When this is done the results can be significant.
Some months ago one of our end-users installed the OEE module at one of their facilities that has a lot of lines. A lot of data has been collected but only recently did the production manager started analyzing it. His attention was drawn to one machine on one line by reason of the OEE. On closer inspection he determined the machine was pausing at times for no apparent reason so he called in maintenance. It's not unusual for automated machinery to slow down or pause due to low product supply or backup conditions but this just didn't seem right. By monitoring the PLC logic maintenance was able to trace the problem to an intermittent field IO block that sometimes gave false state information for some photoeyes.
After the part was replaced the OEE jumped up by 10%. They had accumulated a baseline of OEE information and just by replacing this one part the OEE increased dramatically. In this case the faulty component didn't entirely stop production so its effects weren't obvious. It just made the line not run as well as it could.
This brings me back to the main point. For OEE to work it has to be properly implemented and then the resultant data need to be acted upon. When this is done the results can be significant.
Labels:
Does OEE work,
Downtime,
Efficiency,
Lean manufacturing,
OEE
Is bloatware really necessary?
There was a thread on our forum recently that made the point of how fast and easy it is to install Ignition. I am so glad to see people notice this. It's a big thing. Just imagine your HMI/ SCADA/ MES server just crashed - like a hard drive failure. Now tell me how long it would take to reinstall, reactivate and get all of your projects functioning again. I shutter to think about how long it would take to restore some traditional systems.
With Ignition you're talking about minutes. Seriously, minutes. Even if you have fifteen projects on that one Ignition server this still holds true. (Is it even possible to have fifteen projects on a traditional HMI/ SCADA server?) You just download Ignition via Internet (a few minutes), install Ignition (a few minutes) and restore your single backup file (a few minutes). And with that single file restore all of your communication settings, database settings, project settings - everything is restored and you're good to go. And it will run for two hours at a time fully functional until you reactivate the license which only takes a few seconds. Some traditional systems make licensing reactivation a nightmare - that's crazy. Like kicking a dog when he's down.
Getting back to the main point, I'm really glad our easy install is being noticed by our users. We have so many firsts with Ignition it's easy to lose that message.
The question is, why are we the only ones? IMHO, I think most traditional software was created in the 90's and then tacked-on to, band-aided, and wrappered until it became bloatware. Possibly, as time moved forward and developers came and went (face it, no publicly held corporation is going to keep good developers for very long) later developers didn't understand what earlier developers did so they hacked. How else do you end up with GB installs now requiring DVDs for relatively simple applications?
Then again, maybe I'm wrong. Maybe it was just a lack of good vision and planning from the start. I don't know. All I do know is that it doesn't require DVDs, GBs or hours or days to install and restore a system unless you make it that way.
With Ignition you're talking about minutes. Seriously, minutes. Even if you have fifteen projects on that one Ignition server this still holds true. (Is it even possible to have fifteen projects on a traditional HMI/ SCADA server?) You just download Ignition via Internet (a few minutes), install Ignition (a few minutes) and restore your single backup file (a few minutes). And with that single file restore all of your communication settings, database settings, project settings - everything is restored and you're good to go. And it will run for two hours at a time fully functional until you reactivate the license which only takes a few seconds. Some traditional systems make licensing reactivation a nightmare - that's crazy. Like kicking a dog when he's down.
Getting back to the main point, I'm really glad our easy install is being noticed by our users. We have so many firsts with Ignition it's easy to lose that message.
The question is, why are we the only ones? IMHO, I think most traditional software was created in the 90's and then tacked-on to, band-aided, and wrappered until it became bloatware. Possibly, as time moved forward and developers came and went (face it, no publicly held corporation is going to keep good developers for very long) later developers didn't understand what earlier developers did so they hacked. How else do you end up with GB installs now requiring DVDs for relatively simple applications?
Then again, maybe I'm wrong. Maybe it was just a lack of good vision and planning from the start. I don't know. All I do know is that it doesn't require DVDs, GBs or hours or days to install and restore a system unless you make it that way.
Subscribe to:
Posts (Atom)