Get list of all Tags in SQL Tag Profider

Ignition
1

Hi everyone,

is there a way of getting a list of tags within the internal tag provider.

What i am trying to do is get a list of all tagswith tag names in the internal profider.
When i got the list change the first 4 Chraters in the OPCItemPath property to something else.
Any one ever done something like this?

Other solution would be to be able to change the settings of the gateway via a gateway script
so that one could change the devices ip address to something different.

Regards
Sascha

2

couldnt you just export out to csv from the designer, do a search and replace and then import the tags back in?

3

i need to change the opc path dynamically

4

The only way to accomplish this right now is to put the tags in a database driving provider. That will store the configuration of the tags in the SQL database and you can dynamically modify any tag setting. Take a look at the user manual:

http://www.inductiveautomation.com/support/usermanuals/ignition/database_driving_provider.htm

5

Hi Travis,

Am using the hmi edition for local hmi’s around the place in case the server goes down.
As a result i can’t use database driven SQL as i can’t modify it with hmi edition.
This kind of goes along with the similar scenario of my other post -> “Gateway script to change settings of gateway”
by using the hsql jar driver of ignition in a scrip idea.

Kind Regards
Sascha

6

What would be the process for migrating from the internal tag provider to the database one?

I imagine there is a way of extracting the tag config tables from the built in provider (tag export?.. is this all we need?) and then re-importing it once the pathway for the tags provider has been pointed to the new database

7

Hi Sascha,

Sounds like like your trying to keep a number of panel editions updated automagicly. In this case, can you make the central gateway update the SQL databases for the panel editions?

8

You may also want to look into rolling your own SQLTag driver.

Whitepaper

9

I’ll ramble on for a bit. In my post here I discuss parsing xml into SQLTags. What I did not mention was that this particular application was using an Panel Edition HMI using a Custom SQLTag Driver. With, perhaps, a flux capacitor and a Mr. Fusion thrown in for good measure…

Anyway with a gateway timer script calling it driver script every second (again, plenty fast enough for the application I as working on), everything is contained within the Panel Edition installation. A bit of ingeniousness, if I do say so myself-- which, of course, I do! :laughing:

Hope, between the paper and the script, that this helps you out! :smiley:

10

Hi Gents,

Sorry for the delay,
What i am actually trying to achieve is change the opc tag path to a different device.
I have a set of redundant plc’s (Master Slave configuration).
I don’t want to have all tags there twice so i was thinking of 2 ways of achieving this.

  1. Change the device driver ip address to the required one (dependant on which is the master).
    This would be decided on some tags within the plc and a timer / tag change script.
    however Ignitions driver doesn’t allow ip address change dynamically from within the project.
    OR
  2. Have both devices congigured:
    e.g. Master =192.168.x.x and slave = 192.168.x.x1
    If a change over happened change all tags opc path from
    [Master]DBx.x.x
    to [Slave]DBx.x.x
    problem here is to get a tag list of all configured tags, then changing them.

I think solution one is the neater one with less overhead required.
However now a custom module needs to be made. All other OPC Servers let on change the ip address dynamically as i have described i a previous post http://www.inductiveautomation.com/forum/viewtopic.php?f=25&t=5651 and accomplished with kepware. However i was hoping to get rid of kepware altogether.

P.S. the idea of keeping A Master Ignition System of which all HMI edition could download their projects from would be a nice idea too. i.e.
Have a full Ignition Server with all projects on it.
HMI’s run in client mode as usual, then if the HMI can’t talk to the Server it fails over to itself, running the project from itself and taking up communications to the plc directly for local control.
Now that would be a great feature. This would currently save having to update several hmi’s after a change.
It also would keep connections to plc’s at a minimum as the hmi would only take up communication upon failover.

Regards
Sascha