How do you guys work on tagging your PLC bits to your SQL tags if you do not know what the exact OPC path will be? is there a developer workaround like creating a UDT parameter for the OPC item path or would it be better to wait until the OPC is connected to the PLC?
What order do most of you pull this off?
Half of my PLCs will be PLC5, the others are controlLogix… So, I’m matching the PLC5 tags bit for bit to my UDT anyways…
For Allen-Bradley devices you can just put a[Device]SomePath.BitOf course you have to create multiple tags per bit.
what does this get me?
Lets say I need to map a running tag in my UDT to some N12:18/7
and a Fault to N12:19/9
How would the paths look?
Would I be better off doing this once the connections are made to the OPC?
Well if you want to write to the bit you need to create an OPC tag. Otherwise you can create an expression tag that get a bit out. In UDTs your tag path is dynamic. As long as the .bit at the end is specified it will address a bit.
I always make the tag structure of my OPC Server tags match the structure of my SQLTags. So if I had the two SQLTags Motor1/Running and Motor1/Fault I would set them up like this -
Tags and OPC paths created in Ignition
SQLTag OPC path
Motor1/Running [Device]Motor1/Running
Motor1/Fault [Device]Motor1/Fault
Tags and PLC memory addresses created in OPC Server
Tag PLC Memory Address
Motor1/Running N12:18/7
Motor1/Fault N12:19/9
I never have an SQLTag with and OPC path that is of the PLCs memory, say something like N12:18/7, doing so is a bad system design and is more prone to human errors. The OPC Server should be your ‘Rosetta Stone’ between human readable names and PLC addressing, not Ignition.
[quote=“Pat”]I always make the tag structure of my OPC Server tags match the structure of my SQLTags. So if I had the two SQLTags Motor1/Running and Motor1/Fault I would set them up like this -
[/quote]
How do you mean set up the structure of your OPC? This is done in Ignition as far as I know in the SQL tags browser…
I’m sure that If I could match my UDT to some OPC value that I could specify somewhere else, then this idea would work well (If I’m missing this step, please let me know) I am trying to format all the SQL tags in the same fashion according to a block from Rs5000 to a few random bits from a PLC5 which are going to not only have a different mapping (bit by bit) but also a unique path for everything which I will have to set one at a time.
browsing through another post I found this:
[quote=“thechtman”]Use the following format for the OPC Path.
[Name of device]Address
Where the Name of Device is what you entered when you added the device in the Ignition gateway.
Address is the SLC data table address.
Examples:
[SLC1]N7:0
[MYSLC]B3:0/0
[SLC1]C5:0.ACC
Make sure the data type for the tag matches the data type in the SLC. So B3:0/0 is a Boolean and N7:0 is a Int2, etc.[/quote]
[MYSLC]N12:4/12
ect…
should work for my opc paths right in my individual tags created by my UDT…and I’ll make these all bool types, right?
I actually use a 3rd party OPC server, Kepware to be exact, it allows you to create tags. So I make tags in the OPC server, this is where I make the connection between the PLC memory address (N12:18/7) and the readable name (Motor1/Running). Then I create a tag in Ignition that uses the OPC path of Motor1/Running, not N12:18/7. I don’t think this is actually possible using Ignitions built in OPC-UA server. I make the connection between the PLC memory address and a readable name in the OPC server instead of Ignition for a few reasons - 1) Less prone to human errors, 2) I only need to do it once, and 3) it’s more secure. The OPC server costs less than $1000, it’s a small cost for the advantages it brings.
this is very interesting Pat,
What you are describing seems like a very good solution albeit to a problem I had no idea even existed!
Should I plunge this topic into a feature request and try to configure RSLinx to serve as my free OPC server in the meantime?
PLC5’s are old and it isn’t possible for me to get one to test its behavior in the OPC-UA Ignition server.
I’ve been tagging bits to SQL tags this morning, but I’ve never actually tested that they will work and if I could name them in a third party OPC, I suppose I could create the SQL tags a lot faster and simpler.
I am also curious if your using a third party OPC for your newer PLC tags that use RS5000 for example and have a structured nomenclature, Pat.
[quote=“BigSchottkyD”]…Should I plunge this topic into a feature request and try to configure RSLinx to serve as my free OPC server in the meantime?
…I am also curious if your using a third party OPC for your newer PLC tags that use RS5000 for example and have a structured nomenclature, Pat.[/quote]
Creating tags in a 3rd party OPC server is my preferred way of getting data from PLCs, there are a lot of advantages to doing it this way. One could argue using Ignition to directly reference the PLCs memory is perfectly fine, and I would say in certain cases that’s ok.
I actually don’t use much AB equipment, most of my PLCs are AutomationDirect, so I haven’t really looked at the RS5000.
[quote=“Pat”]
doing so is a bad system design and is more prone to human errors. The OPC Server should be your ‘Rosetta Stone’ between human readable names and PLC addressing, not Ignition.[/quote]
I disagree. first, you end up with 2 spots for typos instead of one. Dont you have to stop and start kepware each time you add tags with this method? sorry, I cant remember.
IMHO, its an unnecessary step. I guess my philosophy is different. I look at kepware as just a path to the data that I want to see.
[quote=“diat150”]
IMHO, its an unnecessary step. I guess my philosophy is different. I look at kepware as just a path to the data that I want to see.[/quote]
Agreed. Although IIRC you would only have to restart the KEPServer on a tag change, and not adding one. Or-- as my brain starts to percolate-- you can disable the Ignition tag then re-enable it. That would negate the need to restart the server for onsey-twosey changes.
I think Pat was meaning that the OPC tag is set up once to address the PLC-- My take is that you still have to do it only once setting the tag up in Ignition. Correct me if I’m wrong, though-- it’s still early here. 
As for security-- Pat, do mean accidental change of tags from within Ignition? Just trying to wrap my head around this one.
I’m not nay-saying anyone’s workflow. I’m just trying to understand it. 
[quote=“diat150”][quote=“Pat”]
doing so is a bad system design and is more prone to human errors. The OPC Server should be your ‘Rosetta Stone’ between human readable names and PLC addressing, not Ignition.[/quote]
I disagree. first, you end up with 2 spots for typos instead of one. Dont you have to stop and start kepware each time you add tags with this method? sorry, I cant remember.
IMHO, its an unnecessary step. I guess my philosophy is different. I look at kepware as just a path to the data that I want to see.[/quote]
Interesting. We do something similar to Pat. We have our own data collection process to get data from protocols that Ignition doesn’t support (like DNP and 61850). We have to create the tags in that tool as well. Mind you, we have modified it so that tags created there are automagicly created in Ignition. I’d like to add the tag creating and protocol configuration into Ignition, we just haven’t had the time yet.
Food for thought -
You might be saying, " I just need to know what the value is that’s sitting in the PLC’s memory location N7:15. What difference does it make whether I have Ignition get the value directly using an OPC path of N7:15 or if I have Ignition get the value ‘indirectly’ from a tag in an OPC server by using an OPC path of MyTank/Level? You say tomato, I say tomoto." Well from the standpoint of just getting the value that resides in N7:15 into Ignition it doesn’t matter, but in the big scope of things it can make a difference.
It’s easier to make a mistake typing in a PLC’s memory address as opposed to typing in a nickname or tag. The fewer times you need to associate N7:15 with MyTank/Level the fewer mistakes you are going to make. If you don’t subscribe to this philosophy then some of these examples will be mute to you.
Here are some benefits to using tags in an OPC server -
(1) - Set it and forget it 
6 years ago I set-up the tags in an OPC server for my customer. Since that time I’ve never had to concern myself with what the PLC’s memory address is for MyTank/Level. Keep in mind that back then my customer was using WW, then I switched them to FPMI/FSQL, and now they are using Ignition. Had I not set up tags in my OPC server there’s a minimum of two additional times that I would have had to remap N7:15 = MyTank/Level.
(2) -Single point of change. Back when I was switching my customer from WW over to FPMI/FSQL a lot of changes were being made to the PLC programs to make them more consistent with one another and to improve network data transmission. This caused a lot of the PLC’s memory locations to change. In my case I only had to go to the OPC Server find the tag MyTank/Level and change the PLC address to say N7:13. Had I not been using tags in the OPC Server I would have had to go into WW and FPMI/FSQL and change the memory locations for those tags since they were using both systems during the change over. How about even in a single Ignition installation, you could have a tag that directly references a PLC memory address, and you could have a transaction group that directly references that same PLC memory address, if that memory address ever changes you need to remember to change it in two different places in your Ignition project.
(3) - Mixed PLC system. Let’s say you have PLCs from Allen-Bradley and AutomationDirect, their addressing is completely different. So if you’re using Ignition to directly map to the PLC’s memory location you’re going to have MyTank1/Level with an OPC path of N7:15 and MyTank2/Level with an OPC path of V2000 because MyTank1 is connected to an AB processor and MyTank2 is connected to an AD processor. So now when you are creating tags in Ignition you’re going to have to remember how to address the memory locations of the AB processor along with how to address the memory locations of the AD processor.
(4) -Consistency of data. I do all the scaling in the OPC server, I know that the values received from tags in the OPC server are scaled ‘real world’ values. Take the case of a mixed system of PLC manufactures again, AB supports floating point values, AD does not. If you were using Ignition to directly access the PLCs memory locations then in addition to having to remember how to address the memory locations of two different manufactures’ PLCs, you now need to remember which analog values you need to scale and which ones you don’t and what is the scaling on those values.
(5) - Less mistakes from the get go. When I’m working in Ignition I have a lot of things going on in my mind, how I want the GUI to look, behave, what data needs to be recorded, how to present it, how the users are going to interact with it, etc. When I’m creating tags in my OPC server I have only one thing on my mind, making sure that the tag MyTank/Level = N7:15 is correct. I’m less likely to make a mistake while creating a tag in the OPC server because creating the tag and making sure it’s correct is my only concern. Granted if you have a small system this isn’t a big deal, but when you get into a system that has 1000’s of tags it becomes a concern.
(6) -Security. Letting other OPC clients directly access the PLC’s memory addresses through the OPC server should be a big No No. You shouldn’t allow another OPC client to get a value from the PLC by referencing N7:15, you should tell them you can get that value by referencing MyTank/Level. What if someone using a different OPC client said they needed to send a value to the PLC and you told them to use N7:5 and they mistakenly typed in N7:15, whoops! You should tell them, sure use the value MyTank/GallonsPerFoot.
(7) - Speed at adding Ignition tags. The tags in the OPC Server are already complete, I need to get that data into Ignition. I have a Tank UDT, I create a new Tank UDT tag, set the OPC path and I’m done. Yes, at some point I had to take time and determine how I wanted all my tags to be structured and enter that into the OPC server, but I did that once, 6 years ago.
I think it’s great that drivers are included with Ignition’s OPC-UA server, and I certainly don’t way to take away from the work they have done, but there are some good advantages to using tags in a 3rd party OPC server.
Pat - great info! It sounds like you're really taking advantage of having another layer of abstraction between the PLC and HMI through tag mapping in the OPC server. That works especially well with Kepware since they have a unified platform that supports so many devices - and in your case since you defined your schema once and were able to make changes above it. I know other people here are successful without that layer - they map SQLTags directly to PLC addresses. In some cases it's about the project size or cost, but often times they prefer to work that way. Our philosophy has always been to leverage the best existing technologies for your project. I'm glad that IA provides useful native drivers, but hearing anecdotal success stories with 3rd party vendor products really puts a smile on my face. Be it an Oracle database, OPC server, strange device communication via modbus, webcam integration, or the crazy configurations that TailFire comes up with - they're all good. I think the "hacker" inside all of us likes to see successful integration. As far as the "best practice" debate, in my opinion, there are clearly bad ways of doing things, but often many different good ways of accomplishing a task. I don't think any of the above posts in this thread are off base.
[quote=“Pat”]Food for thought -
You might be saying, " I just need to know what the value is that’s sitting in the PLC’s memory location N7:15. What difference does it make whether I have Ignition get the value directly using an OPC path of N7:15 or if I have Ignition get the value ‘indirectly’ from a tag in an OPC server by using an OPC path of MyTank/Level? You say tomato, I say tomoto." Well from the standpoint of just getting the value that resides in N7:15 into Ignition it doesn’t matter, but in the big scope of things it can make a difference.
It’s easier to make a mistake typing in a PLC’s memory address as opposed to typing in a nickname or tag. The fewer times you need to associate N7:15 with MyTank/Level the fewer mistakes you are going to make. If you don’t subscribe to this philosophy then some of these examples will be mute to you.
Here are some benefits to using tags in an OPC server -
(1) - Set it and forget it 6 years ago I set-up the tags in an OPC server for my customer. Since that time I’ve never had to concern myself with what the PLC’s memory address is for MyTank/Level. Keep in mind that back then my customer was using WW, then I switched them to FPMI/FSQL, and now they are using Ignition. Had I not set up tags in my OPC server there’s a minimum of two additional times that I would have had to remap N7:15 = MyTank/Level.
(2) -Single point of change. Back when I was switching my customer from WW over to FPMI/FSQL a lot of changes were being made to the PLC programs to make them more consistent with one another and to improve network data transmission. This caused a lot of the PLC’s memory locations to change. In my case I only had to go to the OPC Server find the tag MyTank/Level and change the PLC address to say N7:13. Had I not been using tags in the OPC Server I would have had to go into WW and FPMI/FSQL and change the memory locations for those tags since they were using both systems during the change over. How about even in a single Ignition installation, you could have a tag that directly references a PLC memory address, and you could have a transaction group that directly references that same PLC memory address, if that memory address ever changes you need to remember to change it in two different places in your Ignition project.
(3) - Mixed PLC system. Let’s say you have PLCs from Allen-Bradley and AutomationDirect, their addressing is completely different. So if you’re using Ignition to directly map to the PLC’s memory location you’re going to have MyTank1/Level with an OPC path of N7:15 and MyTank2/Level with an OPC path of V2000 because MyTank1 is connected to an AB processor and MyTank2 is connected to an AD processor. So now when you are creating tags in Ignition you’re going to have to remember how to address the memory locations of the AB processor along with how to address the memory locations of the AD processor.
(4) -Consistency of data. I do all the scaling in the OPC server, I know that the values received from tags in the OPC server are scaled ‘real world’ values. Take the case of a mixed system of PLC manufactures again, AB supports floating point values, AD does not. If you were using Ignition to directly access the PLCs memory locations then in addition to having to remember how to address the memory locations of two different manufactures’ PLCs, you now need to remember which analog values you need to scale and which ones you don’t and what is the scaling on those values.
(5) - Less mistakes from the get go. When I’m working in Ignition I have a lot of things going on in my mind, how I want the GUI to look, behave, what data needs to be recorded, how to present it, how the users are going to interact with it, etc. When I’m creating tags in my OPC server I have only one thing on my mind, making sure that the tag MyTank/Level = N7:15 is correct. I’m less likely to make a mistake while creating a tag in the OPC server because creating the tag and making sure it’s correct is my only concern. Granted if you have a small system this isn’t a big deal, but when you get into a system that has 1000’s of tags it becomes a concern.
(6) -Security. Letting other OPC clients directly access the PLC’s memory addresses through the OPC server should be a big No No. You shouldn’t allow another OPC client to get a value from the PLC by referencing N7:15, you should tell them you can get that value by referencing MyTank/Level. What if someone using a different OPC client said they needed to send a value to the PLC and you told them to use N7:5 and they mistakenly typed in N7:15, whoops! You should tell them, sure use the value MyTank/GallonsPerFoot.
(7) - Speed at adding Ignition tags. The tags in the OPC Server are already complete, I need to get that data into Ignition. I have a Tank UDT, I create a new Tank UDT tag, set the OPC path and I’m done. Yes, at some point I had to take time and determine how I wanted all my tags to be structured and enter that into the OPC server, but I did that once, 6 years ago.
I think it’s great that drivers are included with Ignition’s OPC-UA server, and I certainly don’t way to take away from the work they have done, but there are some good advantages to using tags in a 3rd party OPC server.[/quote]
Pat, you make some very good points that i will keep in mind for future integration.
I am new to Ignition and would like to clear some things. Please correct me if i misunderstood something.
What about the best places of “People friendly (technological) names” of the Tags (e.g. Analog Inputs coming from PLC through OPC Server)?
Disadvantages:
We recommend that you have your SQLTags set up in a folder structure that makes it as designer friendly as possible. Your users never need to see that SQLTags paths (which can have spaces). Also, you can always change the OPC Item path because it is not related to the SQLTag path.