How do I bind a UTD path to a memory tag that is a member of that UDT.
So for example.
UDT:
OPC Tag = Run
OPC Tag = Fault
Memory Tag = Path = ns=1;s=[PLC-H7-SAWP-4]Global.HMI_PressRobot.
I want the opc binding in the UDT for the Run Tag to look something like this:
{[.]Path}{tagname}
This however is clearly not the correct syntax for Path.
Nevermind, looks like you need to define the tag as a parameter, not a memory tag.
You probably could have done it with the memory tag, but you would have had to wrap the expression in a tag() function. But making it a parameter is probably cleaner since it is part of the UDT definition that way.
Yes, UDT parameters are what you pass into udt instances in order to make them unique. For example, I would normally pass in these parameters for my device udts at a minimum:
Then my opcitempaths are set to:
ns=1;s=[{PLCName}]{DeviceName}.sts
So is there anyway to bind the UDT opcpath to a global project opc path? I dont love the idea of having to add these to every UDT. Seems like there should be a global path in the project that they could be bound to. For my case 99% of the tags in a project are going to use the same path/plc. Can a UDT parameter be bound to memory tag not in the UDT?
No
I assume by "UDT opcpath" you're talking about the opc itempath for opc tags within a UDT?
In which case, no, you can't bind this to some global variable/constant/tag/etc.
However, what you could do is to use, as I do, a base UDT which defines all of your default parameters and their default values. One of these parameters could be called something like opcPathPrefix where you could default the value to ns=1;s=[{PLCName}]. Add another parameter for PLCName. and then set this base UDT as the parent of all of your relevant UDT types.
Also, regarding indirect bindings in general (UDT parameters aren't included here). Keep in mind that every binding in the system has a performance penalty. While something might seem like a great idea when you're developing, it's the client performance that your operators will care about. If you put great effort into making everything you can dynamic to make your development life easier, you will significantly reduce the scalability of your project, and the gateway and its clients will likely run into performance issues sooner than later. You also might end up shooting yourself in the foot, as down the track you might find your conditions change, and your web of dynamic bindings might all of a sudden derail (for example, if you were able to globally define an opc item path prefix, but then a second PLC was added to the site, and now you've shot your foot off because your UDTs can only be bound to the first PLC).
Design for performance first, and development convenience second.
Also, tags and UDTs are not part of any project. So a "project" setting for such would be meaningless in the gateway global scope in which tags live.
So what kind of performance difference is there between indirect bindings, vs just using a text editor and hard coding everything on say 100,000 tags at a 500ms scan rate?
Indirect bindings are for user interfaces, not for tags. In general. If you need some tags to be polled or not under various circumstances, leased and/or driven tag groups are the recommended tools.
Ok, my verbiage might be a little off, what kind of difference would you see in client performance?
Huge differences. Not many devices can handle 100,000 tags at 500ms. If you really need to go fast with large quantities of data, and you are using modern Rockwell or Omron PLCs, you might be a candidate for my EtherNet/IP module.
Just to be clear those 100k tags are from over 100 different plcs.
Then it is likely a non-issue. Some Ignition installs handle millions of tags.
