Very good points indeed. And yes, it is rewarding. I’ve always enjoyed industrial controls. It’s like playing with a really big, expensive erector set.
For the last year and a half, for visualizing data I’ve been putting together fancy Access programs that are actually quite effective for what we’re doing. We already own the Office licenses, and our process is simple enough that Access isn’t a bad platform for this. Access connects to the SQL server for its data. For each machine I’ve got two transactions in RsSQL; one inserts a new record every trigger, and the other updates one record.
In Access I’ve made screens that look exactly like the control screens at the machines. I used the updated table to populate this information. The screens show temperatures, pressure, pump RPM’s, and scale weights. Then inside the SQL server I have a view that queries the other table for the current run number, and then Access uses that for graphs so people can see the entire run. So they’ve got the real-time along with the historical.
This is called my “Unit Status” program. The production supervisors love it. They used to have to walk around the entire facility multiple times per shift (it’s a big facility) to keep track of where their operators are in their processes. Now they can keep working at their desks and have this status program open and see exactly what’s going on.
So how is this situation similar or different from what I could do with FactoryPMI? Why should I invest in $3,500 and learning new software, when I might already have this covered?
And exactly what does PMI stand for? I’m pretty sure it’s not private mortgage insurance…
Actually, its funny that you mention MS Access. We have a number of customers who are using FactoryPMI right now to convert existing Access programs over to FactoryPMI, because in some sense FactoryPMI and Access are similar in that they are WSIWYG database frontends. The major differences being that Access has a built-in database of sorts (which you’re not using), and FactoryPMI is much more geared to industrial use.
The main benefit you would gain from converting such an Access application over to FactoryPMI would be the web-launched distribution model. You could make changes to the app from the web-launched Designer from anywhere in the plant, hit save, and the application would be automatically updated on all of those supervisors’ desks. Other benefits would include any increase in functionality that you could derive from FactoryPMI’s richer set of industrial-specific components, trending and PDF reporting capabilities.
Obviously you would have to weight those benefits against the cost of the software and the time of re-working any existing apps. But like Colby said, might be worth a try for any new ventures, and then existing apps could be rolled into the more capable system as time permitted.
Install the FactoryPMI demo if you have time to play. It’s capable of realtime HMI style control as well as higher level summary screens - quite a fun package. The price effectiveness really comes into play when you have simultaneous users, a large project, need remote access, or have unique requirements (including trending or reporting). I support what’s already been said - evaluate what makes sense for your enterprise. Existing systems are a huge consideration.
Thanks guys. I’m glad I’m not alone doing the Access thing (although I kind of thought that maybe I was the first to discover this use for Access). I’ve learned a lot about visual basic programming while making these programs that has helped me revamp other peoples’ Access databases.
I definitely plan on installing it. I might try recreating one of the “unit status” screens just to see it and compare.
Can FactoryPMI connect right to the OPC objects? Everything in my Access programs is essentially old data, even if it’s just 30 seconds old. It would be pretty cool to have ACTUAL real-time data displayed for the supervisors, but that alone isn’t worth the price of FPMI.
I thought I would add my tuppence-worth as a system integrator. FactoryPMI can indeed display real-time data alongside historical. We have already replaced an iFIX system with it to do just that, acting as the main control interface for an Allen Bradley PLC-5 controlling power station auxiliary systems. What we noticed during development was the huge decrease in the amount of custom code we had to write. Python is unbelievably concise compared to something like VBA.
The other thing we have found it amazing for is acting as a GUI for relational databases. I have yet to find another tool that gives its ease of access to data, with built-in tools for easily displaying it. The server/client model is great for systems in the real world. Customers love getting easy access to data on their own desktop PC right across their LAN. Its only downside for this kind of work is cost - its simple pricing model maybe acts against it here. Whether it is cost-effective depends on the number of projects and number of clients you are running.
I’ve been installing systems for over 19 years and I love the ‘transparency’ of the system (best word I can use to describe it). That and the great support
Yes, essentially- that's what "SQLTags" are (you might see it mentioned around here). Technically speaking, FactorySQL is the one connecting to OPC, but SQLTags allow you to work with realtime tags inside of FactoryPMI very naturally.
It should be very easy to bring realtime data in alongside of your current historical info.
