one concern that came up during a recent discussion on migrating to Ignition was that the information RSView32 logs into its various databases is used fairly extensively across our business systems.
Is it possible to log information in the same format RSView32 uses (i.e. tagtable & floattable) natively within Ignition? (i.e. if we wanted to set it up to do a straight switchover where Ignition rather than RSView32 is doing the datalogging?
Thoughts and concerns?
Ignition is pretty flexible with its database interface capabilities. I cant imagine why you would have a problem; however, it might help if you post some more detailed information on the structure of the data tables you are interested in logging to. I would also suggest the best way to be sure about this would be to backup your current database and restore it on a test machine available to a test copy of ignition. From there create a small app that does nothing but attempt to push data into your test data tables. Finally I assume from your post that you are wanting to mimic the structure that RSView is using for datalogging tag values. Where I don’t think you will have a problem logging to the same table formats, you may have a problem or make it more difficult to show trends using that data. Not a tough work around as you could just use the historical capabilities of Ignition in parallel.
Hi AutomationNC,
Thanks for your reply.
The two tables format is as follows
TagTable: (only one record exists here for each tag that is being logged)
Field, type
TagName, string
TagIndex, integer
TagType, integer
TagDataType, integer
FloatTable: (one record for each tag containing tagindex, date, and value, everytime it is logged)
Field, Type
DateAndTime, date
Millitim, integer (milliseconds time stamp)
TagIndex, integer (for building inner joins with the tagtable)
Val, floating point (tag value)
Status,string (not sure what this is for, I don’t use this for my queries)
Marker,string (not sure what this is for, I don’t use this for my queries)
Does this look feasible?
I cant see any reason your data could not be written to tables with those formats. Keep in mind that the first table you list is simply an index of tag names and types that you are logging. You wouldn’t really need to write to that table unless you add tags. The second table has all the values of those tags and the corresponding log times. I think a transaction to log your data in this format is possible if you setup the transaction to include the tag index. I have never done a transaction like this before and you may need to have a separate transaction for each tag. Maybe some of the “big dogs” could comment on that. I also think that would be a pain. Tough to keep up and expand in the future. What would be better would be something that would allow you to keep some compatibility with your old stuff and allow you to add new tags as necessary using ignition’s built in logging capabilities. I think you could achieve what you want better by setting up some views in your database. In this way you would use ignition to log your data using it’s built in format and create a view that formats that data like your business models need to see it. Your view would also need to incorporate your existing data into it to be able to query your older data. that could get interesting… Once again, I would suggest setting up a test system and trying it out so see if you can get it to do what you want. One thing about Ignition - there’s enough flexibility to allow you to do pretty much anything you want. I have not hit a development wall yet.
Hmm, I’ve tried this before (setting up a view to look like a table before) with RSView32 I was trying to mess with the RSView32 trends to show custom overlays by having the underlying datalog model point to a view rather than a table in the hope that it would retrieve the information that I placed there. I wasn’t able to get it to work however and the Rockwell Tech I spoke to said the way it accesses information wouldn’t allow this. (Needs a table to look at)
It might work for stock queries from excel or other business systems (mostly vba or old vb6 based programs) though
We may be looking at having both systems operate in parallel it seems unless someone has some other ideas.
How would I get the table information stored in this format to display on the trends in ignition?
Hi,
That format is really pretty much conceptually identical to what SQLTags History does, so I do think that with the crafty use of Views it should be possible to integrate the two systems.
In terms of using the data in Ignition, there are several options:
Questions: do you need to log new data back into these existing tables from Ignition? Will you be logging other, new, data from Ignition in parallel? That is, would you expect to have SQLTags History tables side by side with the old rockwell tables?
Which database system are you using? (sorry if you’ve already mentioned it somewhere) It’ll help me judge how easy different things are to do. One idea I have is to create a new schema which will be the “bridge”, and a new database connection in Ignition that goes to this schema. This is all to keep it sandboxed, and because Ignition creates SQLTags History Providers based on database connections. In that new schema, you would pre-define views that mimic SQLTags History (I would obviously help you by providing a definition of what it expects). Those views would then access the schema that contains the RSView data. In Ignition, you would have two SQLTags history providers- the normal one, and the “rsview bridge” provider. You could now easily graph the data by using the tag history binding on the easy chart, tables, etc. SQLTags History allows querying from multiple providers at the same time, so it would be fine if you were logging new data to the “normal” provider. If you wanted to log new data to the old format, it would be a tad tricker, but I think still possible.
Regards,
Thanks for your reply Colby.
Our database engine in this case is MS SQLserver 2005
I’d like to keep any system as simple as possible, even if this means logging the same data twice (albeit in different formats). One of the things that regularly breaks down in our rsv installation is the datalogging functionality so I’d like for this be one of the first objectives to go after as part of a migration.
How would we log data to the same format? would this be through ignition or would we have to convert the information through scripting in SQLserver from one table to the other?
Colby, you actually looked at this from a direction I had not thought of. I assumed that the older data would only be needed by the business systems. If they needed to see that data at the field SCADA level, it’s nice to know that the data is available with the classic chart. Alex you may need to elaborate on whether it is necessary for Ignition to pull from your existing data. If not then the parallel setup might still be practical. Using transactions to log your data in a format suitable for the business systems and using the built in logging to make it easy to create charts and trends at the SCADA level. I guess you would need a separate transaction for each tag since they will all log to the same data table field, but I’m not sure. Never attempted what you are wanting to do. Colby is there a way to combine all the tags into a single transaction?
Hi,
Alex - to log to the same format, you would have two options (and a half): set up transaction groups that map to that format (the half option: write a stored procedure and map groups to it), or use updatable views to map to mimic sqltags history and map across.
The simplest option, in my opinion, is to use SQLTags History and just log data separately. But, having data twice isn’t the greatest solution, and a lot depends on how much you want to integrate in old data.
If you were going to use transaction groups and map them, I suppose you might as well map to the old format, though there may be some difficulty with the idea of tag ids. Also, setting this up with transaction groups could be a little more work than you’d want which gets me to…
AutomationNC - In one scenario, you would have a tag per group. This would really not be desirable though due to the weight of each group and work of configuring. A second option, which is better but slightly less flexible is to use Block Groups. These have a mode that will “insert changed rows”. You would create a block item for the tag path, the value, quality, and timestamp.
This comes up from time to time and we have some ideas of how to make this easier with the transaction groups. We have lots ideas for the SQL Bridge module in general, hopefully we can get around to working on the next version soon.
Regards,