I have a project where the customer wants to use Ignition Edge. So the setup will be a single Gateway with 1-2 Perspective sessions maximum. They want to be able to configure the project to easily talk to either a Schneider Modicon PLC or an Allen-Bradley PLC. What I'd really like to do is be able to dynamically generate an OPC tag path in each tag based on some kind of selection. I'm initially thinking a memory tag in the project denoting which PLC is connected. Is there a way I can have tags dynamically switch their OPC path based on the value of this tag? Can I make the OPC Path itself an "IF" expression?
Ignition Edge supports connecting to multiple PLCs. Set up two folders, each folder contains respective tags to separate PLCs, and have your bindings on components dynamically select from the two folders based off of some condition.
3 Likes
@bmeyers's solution is probably going to be your cleanest one as you could even set up an expression tag as your "dynamic" tag if your selection logic is simple enough. (I guess that wouldn't be two-way though)
If the OPC paths only differ in a small portion and it's a reasonably compact subset of tags, you could also set up a UDT, which lets you substitute within OPC paths using parameters (no expression logic) and configure the parameter manually. This would be a nice way to have two-way bindings almost automatically.
I can also think of a hacky way with tag.configure but it's potentially the most error-prone, so I won't go into detail here.
I would rather avoid this if at all possible. The customer is adamant they don't want to have to maintain dual projects in any capacity, which would extend to having to maintain two tag databases where adding anything to the standard would require double the work.
Obviously, what's possible is possible, but we do something similar in Wonderware for other customers in the same situation, so I have to believe it may be possible in Ignition as well.
Except it's Edge, so you have to purchase the Compute plugin.
Best bet is probably a UDT.
It's going to be much cleaner if you do this in some way. I would make 2 identical folders in your UDTs, one for Modicon and one for AB. OPC paths are generated for each based on your supplied parameters. Then dynamically bind based on the PLC connection that is needed.
Compute is now included (I believe that was the old name for the one that enabled scripting, right?)
2 Likes
Well, guess it shows that I never use edge
1 Like
Yeah, I don't know if the OP is using post-8.1.33 Edge which now includes Compute by default:
That's what I was thinking at first. The customer doesn't want to maintain two projects, but if the only possible way to do what they want is just having to maintain two tag databases, that's still better than two different brands of HMI (Panelview and whatever Schneider's current offering is) with different graphics, navigation, etc.
This is a new job so yes I'll be using the latest version.
EIther that or be very strict with their tag naming and organization so the only differences between paths in the two PLC types would be minor. Full disclosure that I've never worked with Modicon so I have no idea how their tag paths are organized.
Not going to happen. I'm not familiar with recent Modicon stuff, but the programs are very different and we're to avoid changing the PLC programs at any cost. A real "two arms and a leg tied behind my back" kind of situation. I'm not even sure if I'm dealing with a verbose tag structure on the Modicon side with UDT structures there or if I'm just going to have a bunch of 40xxx modbus registers to deal with.
1 Like
A quick search turned up nothing but Modbus TCP type addressing, so yeah, you'll pretty much have to maintain two lists of tags in some way or another (unless you rename all your AB tags to use the equivalent Modbus address and put them all in global tags but if anyone did that it would be a support nightmare)
1 Like
Outstanding.
You're not going to need 2 projects. You're going to need 2 tags, there's almost no way around that. You could use scripting to refactor every tag's OPC address, but that does not seem worth it to me and it does not feel very clean. This is because the OPC path does not evaluate expressions.
If you do it the UDT route you're not "maintaining 2 different tag databases" the 2 tags will be made automatically. You just need one tag that is used in an indirect binding to swap between the two for every tag.
I don't think I'm following. My initial thought was:
- Create standard Ignition UDT structures for things like tanks, pumps, valves, etc.
- Model those on the Allen-Bradley UDT structures that already exist.
- Make an identical tag database with the same UDT structures, but the Modicon version will just have individual elements pointing to modbus addresses in the OPC path instead of Allen-Bradley Tags.
- Have the customer either import one or the other tag database when they make their project.
Are you saying I can accomplish this with just one tag database? I'm not sure I can use an indirect binding because the tag names are so different. the A-B tags are structured in UDTs, but the Modicon tags will all be unstructured Modbus registers. There's no "formula" that allows me to easily change from one to the other with a simple binding. They'll all be completely different and there's no rhyme or reason between the two.
Well that sounds very fun... So, even if you could dynamically change which PLC to look at, since there's no real way to figure out which Modicon tag you should be looking at from the AB tag path that point is somewhat moot.
I'd handle it like so, using a tank UDT as an example:
- Make your base
TankUDT.
A. Since your AB stuff is organized you an include those parameters and generate the OPC paths that way, but you'll have to manually override the OPC paths for the modicon tags at the instance level. - Make an
AB_SE_TankUDT.
A. This will have 2 instances of theTankUDT - "AB" (Allen Bradley) and "SE" (Schneider Electric) - Make instances of the
AB_SE_TankUDT.
A. You'll have to manually go in and override the OPC path for the SE tags. - Now, when you go to bind to a tag you use an indirect binding of
[default]Tank_1/{1}/Levelwhere {1} is either "AB" or "SE"
I assume when you say "tag database" you mean "tag provider".
In this picture I've created a tag provider DualPLC and created 2 folders AB_PLC and Mod_PLC. Each folder is identical except for the OPC path.
You then need some condition that triggers if your component looks at the AB_PLC folder or the Mod_PLC folder. In the picture I am using a toggle switch but you could check the client hostname at startup or based off who logged in.
It also sounds like you are hung up on having Ignition tag names that aren't related to PLC tag names. They do not have to be, and usually shouldn't be. Just make your UDTs have the same member names in both versions, no matter what the PLC tag names are. Then the user interface can point at either implementation with identical UI functionality.
4 Likes