FTView SE Network new tag setup

Good day, folks. Our plant uses Factory Talk View Studio SE distributed (V8.0) as the HMI package to our roughly 10-20 PLC5/SLC500 processors. It's a huge package involving hundreds of screens & thousands of HMI tags. HMI Tag addresses are all bunched together in the PLC; i.e. PBs are assigned to B18, Indicators are B19, Analogs are N21, etc.

We're beginning to migrate the older PLC technology over to 1756 & 1769 Logix based processors. I want to take advantage of the UDT & other features offered in the new PACs but I'm not sure what's the best practice nowadays for setting up tags between PAC & HMI.

Looking at Chapter 10 of the Design Considerations manual shows me that structures can be used, but packets are optimized when atomic arrays are used. I'm looking for some direction. So what have others in this situation done?

a. Keep using arrays of type DINT, Real, etc. in the PLC and map them over to my UDTs.

b. Never mind the optimization, let FTView read from/write to the UDTs.

c. Some ingenious plan I haven't thought of yet. (Details must be provided if answering C)

Thanks in advance.

Here, I only use 'b'. Linx will dynamically cache and activate/deactivate tags as needed by its client, and while tags scattered around randomly might be a tad slower, I've never seen any difference from either the user perspective, or even the communications diagnostics perspective.

Thanks rdrast!
For a particular object, would it be best to put all of the HMI input elements & HMI output elements into the same UDT or create separate UDT tags for each?

For a simple example, let's say I have a 2-way valve UDT.
The HMI writes BOOLs the following to the PLC:
AutoPB
OffPB
ManPB

The HMI reads the following BOOLs from the PLC:
AutoInd
OffInd
ManInd
ValveOutput

Does one have an advantage over the other?

Just leave the UDT's as they are and point the HMI to it. There's a huge time saving in development by creating a global object/popup screen for "2-way valve". Just assign the .AutoPB, .OffPB, .AutoInd, .OffInd etc to the global object, and then for every valve in your system, all you have to do is attach the global object to the UDT instance and you're done.

Exactly what ASF said.
Write your program to be clear, and don't worry about the comms.

Make your UDT's/AOI self contained and logical.

rdrast said:

Exactly what ASF said.
Write your program to be clear, and don't worry about the comms.

Make your UDT's/AOI self contained and logical.

Click to expand...

Whole-heartedly agree with your advice. Thanks.

I've seen programs where it appears someone tried to create one or two tags of UDT with thousands of sub-elements and ultra long tag names. I'd prefer to have my tags represent solitary objects (motor, valve, transmitter), system modes or a grouping of objects when applicable (silo, etc.). Seems like a much more logical way to handle things.

Just out of curiosity, approximately how many tags have you worked with in a setup like this?

The largest I have here is 56,000 tags in the PLC, 33,700 tags in the FTView HMI.

For the record, I do have single compound UDT's made up of other UDT's, with approximately 800 sub-tags. Each of those encapsulates everything for a single machine section.

rdrast, I've done the same thing back when working for a systems integrator. Didn't mean to imply that it was wrong.

My current situation is where I'm adding some equipment to an existing system, hence the individual component tags. I'm honed in on the task at hand so that was the focus of my comment. Trying to avoid scope creep...

Your tag count has me feeling a bit more comfortable as I undertake this venture! Thanks again.