SQLTags represents a significant change in architecture for FactorySQL and FactoryPMI. While our core architecture of web-launched clients and database-centric data storage hasn’t changed, the techniques used for configuring status and control screens have changed greatly. This guide is meant as a primer for existing users of FactorySQL and FactoryPMI. It will explain the design rationale of SQLTags, introduce the new features, and to provide some motivation for why it might be in your best interest to upgrade your existing system.
SQLTags is an underlying technology in FactoryPMI 3.0 and FactorySQL 4.0. These versions are completely backwards compatible. SQLTags works by creating a high-performance tag database inside your existing database. It does this by creating new tables that both FactorySQL and FactoryPMI will use. Because both FactorySQL and FactoryPMI “understand” how these tables work, you (the designer) no longer need to be concerned about writing SQL queries to interface with your data. Rather, you simply deal with “tags”. In essence, we’ve more tightly coupled communication between FactoryPMI and FactorySQL, but all data is still in the database so that we don’t lose any of the much-loved flexibility, scalability, and simplicity of our database-centric architecture.
It is important to note, however, that SQLTags currently only deals with real-time status and control data. All history, downtime tracking, etc is accomplished in the same manner as before. There are future plans for a historical addition to SQLTags.
Tags are addressed by their path, which looks like this:[MyDB]EastSection/TankFarm/Tank15.value
The first part, in square brackets [MyDB], is called the source. Typically this will be the name of your datasource connection, or simply blank to use the project’s default datasource. The next part is the path to the tag with forward slashes as folder delimiters. Lastly, one of the tags properties is referenced (in this case, “Value”). If no property is present, Value is assumed. Tags have lots of properties, such as Value, Quality, Documentation, EngUnits, etc. See the documentation for a full list.
Tags are used in your FactoryPMI projects via the familiar property-binding paradigm. Just like you are used to binding properties to expressions or SQL queries, you can now bind properties to tag values. You can bind to most properties of a tag. You can also use tags in expressions and SQL query bindings.
Even better, you can simply drag a tag and drop it onto a component. Depending on the component and the type of the tag, appropriate property bindings will be added. Or, if you drop a tag onto a container, it will prompt you to create an appropriate component to display that tag. Lastly, you can drag a tag onto a property, which will add a binding to that property.
New with SQLTags is a status overlay system. Each component in FactoryPMI will calculate its quality based on the worst quality of any tag bindings configured on it. If the quality is anything but GOOD_DATA, you’ll get a noticeable visual overlay on top of the component. This is a crucial part of SQLTags – with no extra effort, you get reliable status indication on every component on your screen.
With SQLTags, you can create a new tag manually by pressing the “New Tag” button on the SQLTags Browser Panel’s toolbar. Even better, though, you can now browse your OPC servers from the Designer! Simply open the OPC browsing panel and your FactorySQL instance will be listed. From there you can browse the OPC servers that are available. Drag OPC items into the SQLTags tree to create OPC tags based on those items.
Writing to tags is very simple – simply check the “bidirectional” checkbox on your tag binding. This is applicable for bindings on properties that change as the user interacts with a component, such as a numeric input field. There are also 3 new control buttons in this release that are made specifically to work with SQLTags:
All 3 of these buttons can be configured simply by dropping the appropriate tag onto them.
As mentioned before, SQLTags is a highly scalable system. The load to the database, which has until now been variable with the number of clients, is now fixed. The Gateway handles all SQLTags polling activities irrespective of how many clients are running. Clients then poll the Gateway, which is highly optimized to handle a large number of concurrent clients.
As of this writing, we hadn’t performed formal benchmarks yet, but preliminary benchmarks look promising. A quick in-office test with FactorySQL, FactoryPMI, and an un-tuned MySQL database running on a desktop machine served 93 clients running a load test application that handled over 35 tag changes per second with under 50% CPU utilization.
All input components are touchscreen-enabled by default now. No more need to handle touchscreen events with mouse scripts anymore. Don’t worry, this was done in a backwards-compatible manner – your old scripts won’t step on the toes of the new automatic system.
SQLTags completely obsoletes the “old way” of implementing status and control. Using SQLTags, one can implement a more scalable, more reliable status and control screen in much less time compared to FactoryPMI 2.0. The good news for existing users is that it is backwards compatible, but also easy to convert. If you want to convert your existing status and control screens, all you need to do is drag your OPC items into the SQLTags tree, and drop the appropriate tags on top of your existing status and control components. Want to see more? Call us for a personalized web-demo.published: 04/30/14