Changing Tag (from Ignition project) name before entering Canary Historian
We've got existing systems that did not use historian database capabilities and I am introducing the concept to the business units. I understand the concept of data historians, but have never actually stood one up from scratch.
In past lives, I've had the collector system use generic names for the equipment common throughout the 100 or so plants. Then we mapped the actual tag to that IO item. That IO item was then actually historized. This gives our tools a common reference point when the individual sites have no such organization. We are not 100% on this, but for core reports/graphs etc it sure helps.
Right now, without having a lot of experience in Ignition and/or Canary, the best I can think of is to create a set of naming conventions to use when building site specific historian rollouts. These expression tags would then be connected to the actual ignition tag collecting the information. Then we historize the expression tags so we can have usable data in the Canary Historian.
For instance every line has a tag called Line, Order, Product. My question, is there an easier way to do this so a user can create a chart in Axiom so they can choose the applicable tags they want to analyze.
For instance they want to see the exact weights of a packaged finished good item to measure the 'give away' (too much material used in the finished good). This product was called for by an order number and was assigned to an assembly line. This assembly line has automated scales attached to the four lanes of products on the conveyors carrying the finished goods. Right now we have 5 assembly lines all with a Name tag. They also have 4 scales - one for each lane which have a tag called Scale1-4. These scales weigh every finished good and that weight is carried in a tag called grossWeight.
As I'm building a test for one of the assembly lines, this structure appears to work. But when I try to scale it up to the "n" number of lines (all of our plants are different), I believe I'm going to run into an issue because I cannot differentiate even an order to identify which is running on one of the assembly lines (therefore, i don't know productID, maxWeight, targetWeight, and minWeight type data) because that was assumed in a single assembly line configuration.
So, if I create a naming convention of standard tags to historize, I should be able to allow our team to select appropriate tags from the historian (or I can build them based on criteria they provide).
I see something like this:
<country>-<siteID>-<area/department>-<line>_<TagCategory>_<EquipID>-<TagName>
US-MST1-PRD01-AS2_Scale_SCA01_WeightMax
US-MST1-PRD01-AS2_Scale_SCA01_WeightMin
US-MST1-PRD01-AS2_Scale_SCA01_WeightTarget
US-MST1-PRD01-AS2_OrderInfo_CurrentOrderNbr
US-MST1-PRD01-AS2_OrderInfo_CurrentCustomer
....
Then I thought, hey Canary may be able to do aliases of some sort where I can historize the tags already being used and give them a different name within Canary. Saving me from having to do that in a centrally controlled environment. Ideas?
2 replies
-
Hi todd. frahm ,
Our Views service is what handles this "aliasing". We collect data using the tag name provided to us from the source, whether it be Ignition, an OPC server, an MQTT broker, etc.. If that tag name does not have the desired naming convention you want to expose to the end user, Views can modify it. You can build what we call a "virtual view" on top of the raw data that comes into the historian. A virtual view does two main things:
1. Modifies the tagpath to achieve the naming convention you desire. This would be the aliasing I was talking about.
2. Define assets within the model. In your scenario, you could define what a site, area, line, category, and equipment asset is.
It's also important to note that Canary uses a period (.) to indicate a new branch in the tag hierarchy. So if you can't change that at the tag source, we would do it in a virtual view so that your tag would like [Country.Site.Area.Line.TagCategory.EquipID.TagName].
We build these virtual views using Regular Expressions to match string patterns within the tag path. I would look through the Views section in the knowledge base to familiarize yourself with that process. Specifically, I would look through Virtual Views and Asset Models Primer as well as Creating a Virtual View.
Hope this helps!
-
GREAT! I appreciate the quick reply and references for me to look at.
TF