I found this technique very interesting for converting large amount of Tags and Alarms into Ignition compatible xml file. I found this idea in youtube just few hours back and still experimenting. I thought, i will post it here immediately so that you can also try and share your experience. Cheers
First, we have to create an XML schema xsd file. Schema is our template.
In Ignition, basically we can create UDTs and 5 different types of tags.
Create some sample tags (or UDTs) under each type, export as xml and save it as .xsd schema file . Let's say, we have 6 sample schemas.
Classify your csv list of tags and alarms which needs to be converted as xml, into 6 types as per your 6 schemas. Save it into 6 Excel sheets.
Now, you have to just map your Tags and Alarms in Excel sheets with the respective schema.
Watch these videos and dig deeper.
Convert Excel Spreadsheet data to XML
Converting XLS to XML
Converting data from Excel to XML Template
Import & export XML data, XML maps and schema in exce
I suggest, IA can invite them to dig into Ignition and roll out their own training courses, in their own style. They have a huge following and this will help Ignition spread. They are looking for opportunities.
If you are asking about freelance tutors and private training institutes for WW, FTV, WinCC etc, just search plc SCADA training in Youtube. You will find a lot worldwide. I wish, Ignition too spreads like this.
I think you missed my favourite topic USD 99/- license. May be you will find it interesting.
I went to youtube and searched that terms, and I didnāt find anything overly helpful. It seems like IA is much farther ahead, mainly because of Inductive University. Just my opinion however.
I saw the discussion about the $99 license, I chose not to comment.
As for importing tags, writing a csv parser that adds the tags to the tag engine should be relatively easy.
yeah, I developed a window that has the properties of tags I normally use in tables. I also can import from csv into those tables if it is a large amount of tags. I then have a script that will run thru the dataset and create all of the associated tags. Took a few hours to setup but has saved me many more. Im not sure how newer versions of wonderware work but fooling with that crappy csv file that would never import right was painful compared to using the tag creating and editing methods available via scripting.
I know Iām late to this post, but it came up as Iām searching for tips and tricks to exporting and importing tags. I am kind of disappointed in some of the responses to the original author. What heās asking seems perfectly reasonable. A lot of Automation Engineers and SIās are not software developers. And we still love Ignition! And we can still be successful in Ignition and work really hard to learn and write scripts to solve problems as needed, but it doesnāt come easy.
Iām about to go down a huge, XML, XSD, JSON and scripting hole in order to solve this problem. And I do believe it would be nice if people that have done this effortlessly would share the knowledge. There isnāt a day that goes by that I donāt have to google an LED or a question about something I run into. Iāll figure it out, probably tomorrow. But, I have lots to do:) Iām a long time Ignition supporter!
Donāt be intimidated by scripting. Python is easier than complex Excel formulas (which Iāve also worked plenty with). See system.tag.configure. Itās not hard to figure out (there are examples there) and it is very flexibleāmore useful; and less time consuming than Excel based solutions Iāve used in other SCADA systems. You can also search this forum for system.tag.configure.
Play around with it in script console until you have what you want. If you get stuck, start a new post here showing what youāve done, what you got, and what you expected to get and chances are people will jump in to help you figure out anything youāre stuck with. The community here is definitely one of the best going in the automation world. Show us what you want to do and thereās a good chance youāll get help. The more detail you give in your question the better the answers will be.
I am also pretty disappointed in this feature, and I am relatively comfortable with scripting. Ignition is generally quite intuitive for new SCADA engineers, and this is one area that is not intuitive. For a new project, the tag creation tools are great, but in situations like migrating a tag database from one platform to another ā this can be done in like 15 minutes with CSV exports, but with Ignition I need to build my own tools to transfer tag data from CSV format to XML or some other custom approach?
You still can import CSV tag exports into every Ignition version, including Ignition 8 - youāll have to manipulate them into the appropriate format, but the same is true of any other import tool.
A genuine question - how would you like the experience to be better? Moving away from XML (or JSON, in Ignition 8+) for Ignition tag import/export isnāt feasible, because the CSV format simply doesnāt support the complexity of Ignition tags. If youāve got specific ideas, though, weāre happy to hear them - we do genuinely want to make the experience as good as possible.
Iāve seen that you can import CSV, but I donāt know what the appropriate format is since I cannot create a CSV export. Maybe just obtaining an example CSV export is all I need.
I understand why the XML/JSON format is necessary to support the structure of the Ignition tag database ā the way tags are handled in Ignition is a big improvement over platforms with āsimplerā tag databases, like iFix or InTouch. There a serious limitations with having the tags all lumped together like that, but it does make it so much easier to go through the tag exports and modify as needed.
I appreciate the complexity and flexibility of the Ignition tag database, but some projects donāt require that level of organization and detail (and usually these are ones that are more budget constrained, or dealing with legacy tag structures ā i.e. lack of structure), so itād be convenient if there was some sort of bridge between an unorganized tag import/export and the current method. Where you could do the basic CSV export/import if you wanted, and it doesnāt have the full capability of the XML/JSON method, but it allows you to get the tags into the project easily and you can go from there.
Or otherwise, developing a tool in Ignition that aids the import/export process, rather than requiring the user to develop custom scripts that automate the tag creation process. It seems like most people replying to this thread have their own specific way of doing this, so itād be great if something like that was just built-in. It seems to be the kind of tribal knowledge that I usually see among the older platforms that Iām not accustomed to seeing with Ignition (I will admit, I am spoiled. With any other platform, I would just accept the futility of it all ā the fact that I reached a developer within minutes of a spontaneous frustrated forum post is a great illustration of how far ahead of the pack Ignition is).
I donāt think that there is such a ātoolā in any (or for any) of the existing SCADA systems out thereā¦
Yes, you can export tags to the CSV but only to import them in the same SCADA software you exported them from.
How you would import the tags from iFix to Wincc for example or vise versaā¦
The ābeautyā of importing tags with python scripting in the Ignition is, that CSV format doesnāt matter.
With 20 (10 if you donāt have alarms) lines of code in the Script console you/I can import tags from any other software out here. From any CSVā¦ or from multi CSVs at once.
Show me any other existing SCADA software out there that can do that.
Donāt be afraid of scripting. 10-15 minutes of scripting for importing ten thousands of tagsā¦ and next time is far less, because you just make corrections to the existing scriptā¦
yeah take a little time and use scripting to create the tags. There is no one size fits all option because Ignition gives you alot of options on how you configure your tags.
If you cant write the script pay someone a few $ to help you. It will be worth the money when you can massage a csv file from another system, then create tens of thousands of tags in a short amount of time. Plus this is something that can be reused many times over.
Hi
I do this by putting my tag lost in a csv file with my custom data and create a script to import and parse it and use system.tag function to create or modify my tag.
This is the only way to import bulk of tag into ignition without using XML.
Expecting the end user to create a script to import alarm tags in a format which isnāt published is not a good policy IMO. Several integrators in this thread have mentioned that creating this script can be a competitive advantage and that itself should be a red flag that something is wrong. Many in this forum believe it is bad practice to utilize tag change scripts (within the tag), in most circumstances preferring instead to utilize gateway event scripts. The same rationales would apply to alarm tags. I believe alarm configuration should be done in a similar way to project gateway event scripts. That way all the alarm configuration can be accessed in one location for the applicable project and configuration and maintenance would be simplified. Drilling into each alarm tag to make an update or to verify configuration is quite cumbersome.
It may be that the configuration needs to exist at both levels. There are use cases where the tag change scripts are better suited one way or the other and the same would apply to alarms. But in the end if users had to pick between one method or the other most would choose the project gateway event method.
In reality, the end user give us a list of tag in Excel and you can do some simple modifications on that and them write some script which is totally fine to create those tags for you. The modifications involve defining UDT for those tags. So all alarming, history and meta data of tag is already define in ignition in UDT and you only create those UDT.
Using system.tag.edit is good and solid choose here.
Compare to XML or json format this method is more human readable and easy to maintain.
