We frequently use the SQL tag editor from the freebies for FPMI. With realtime internal tags how will this work since they are not stored in the DB. It is very beneficial for us to edit these from the runtime.
Great question. We’ve talked about this a bit internally, and we think the best option would probably be for us to simply have a tag editor component that could be used within the Client runtime.
The other option would be for us to expose a more robust tag editing scripting API, and then you could roll your own window that would use this API rather than the direct database interactions of the past. This is probably more likely in the short term.
In the meantime, you can do a bit of this by simply writing to the tag’s properties, but we are aware that this doesn’t really work for the more complex properties like alerting config.
We have a customer that wants to be able to change analog alarm limits without using the designer. ie from within the app. I was looking to see if I could change the limits on a SQLTag via scripting.
In the meantime, you can do a bit of this by simply writing to the tag’s properties, but we are aware that this doesn’t really work for the more complex properties like alerting config.[/quote]
mean I have to look at other ways?
One way to expose the alarm limits is to create DB Tags for the low or high setpoints of each analog alarm state and set the states to Tag-Driven. It could create a lot of extra tags for you to manage, but isn’t unbearable.
Yeah, there are really two ways to have runtime-settable alert limits:
Use a DB SQLTags Provider so all of your tag definitions are in an external database, and modify those definitions (ala FactorySQL & FactoryPMI)
Set up your alert limits to reference other tags, and the let the user’s modify those tags (Good for when only a small number of tags’ alerts need to be configurable)
The 3rd option is to wait for the upcoming system.tag.alterTagAlerts() function, which should be included in 7.1.
Further question about SQLTags.
Our data is placed in the database by our own software which is not OPC. To date we have not used SQLTags for this reason. So I’m trying to figure out if we should start.
I’m guessing that SQLtags poll the db for changes. If I create a couple hundred SQLTags for the analog points I want to alarm/historize, will my db be hit with hundreds of selects a poll cycle? ie: one select per point?
Each time the SQLTags system polls the database for changes (several times a second), it is basically saying: “select everything where valuechange>last check”. So, 2 points: 1) There is only 1 query per cycle and 2) It’s selecting based on an indexed timestamp, so the query is very fast.
Would you be driving the values from your own application, or are you just asking in general?
Yes, the values are being driven from our application.
How does that work when the tags are bound to an sql?
Or have I missed something about defining a tag when the datapoint is in a database?
Should I bind the tag to an expression? Will it be monitored if there is no client running?
I think Colby was assuming that you would be using db tags that weren’t bound to anything, and have your application “drive” them directly by interfacing with our sqlt_core table. If you want your tags’ values to be calculated by using a custom SQL query expression per tag, then yes, they will have to poll those queries independently.
Now that’s an interesting idea. You mean I can create a table full of tags that SQLBridge polls, but that a 3rd party (eg: my app) can update.
I totally missed that while reading the documentation. That might actually work.
Well, it’s not really something we highlight too much, so it’s understandable you wouldn’t think about it after reading the manual. However, with “external sqltags” as they’re called now, everything is in the database, so you could technically drive them yourself.
Basically, if you have data being driven by your own app, you have a few choices:
- Pull the data in directly through db bindings on component properties, or dynamic dataset properties that pull in blocks of data.
- Create SQLTags that run queries to get the data.
- Drive the SQLTags model yourself.
Which method you use depends on a variety of factors- how you want to use the data, how much data you have, and how easily it is for you to modify your driving application. #1 and #2 are done purely from Ignition and work with your current db/application structure. #3 will be much more efficient if there is a lot of data.
SQLTags is designed to support multiple “drivers”- previously these were multiple FactorySQL nodes writing driving values in a single database, and now are multiple Ignition/SQL Bridge nodes using the “external database driver”. Your application would just be another driver. You’ll define tags in the SQLTags schema, and assign them a “driver name” that tells the other nodes that someone else is driving the value. Then, in your app, whenever a value changes you just set it in the correct value column, and update “valuechange” to be the current time. This tells everyone watching that the value has been changed.
We can give you a bit more info if this sounds like the road you want to go down.
Currently we are using option 1.
For a bunch of reasons we are looking at option 3.
What do I have to do to set the the required tables?
Feel free to contact me offline if you don’t want to go into details here
Because of increased interest in that recently, I think I’m going to throw together a white paper tomorrow that outlines how to drive your own tags. I’ll let you know when it’s available.
I’d be very interested in this white paper as well …
Will the white paper be made available to forum members?
I too am interested in this.
It’ll be up on Monday. It’ll be available to anyone who wants it, I’ll post a link when it’s up.
See this forum post for the paper.
Any update on this?
[quote]Great question. We’ve talked about this a bit internally, and we think the best option would probably be for us to simply have a tag editor component that could be used within the Client runtime.
No, no updates. The feature request is pending in the system, but it isn’t a very high priority right now.