FactoryTalk View SE V10- Hide unused objects in a Global Object?

V 10.00.01
Patch 6

Is there a good way to hide unused values or objects inside a Global object? I have a number of pumps and rather than creating and then updating numerous global pump objects I’d like to hide values that some pumps don’t have. I tried visibility based on the Global objects parameter value being a string “Disabled” but while there were no errors the visibility animation did not work.

Thanks.

I have an "AlwaysOn" system tag and an "AlwaysOff" system tag. Just link the animation to global object parameters and for each instance use the AlwaysOn and AlwaysOff tags to determine whether they show up or not.

It looks like it works with another Global objects parameter. I linked the visibility to a new Show/Hide Global objects parameter value, it took a few time tries to get the syntax right.

No
{#405} == 1
{#405} = 1
"{#405}" == "1"
"{#405}" = "1"

Yes
#405 = 1

ASF said:

I have an "AlwaysOn" system tag and an "AlwaysOff" system tag. Just link the animation to global object parameters and for each instance use the AlwaysOn and AlwaysOff tags to determine whether they show up or not.

Click to expand...

If its something like pump speed, do you just keep the bad global object parameter for the speed and use another global object parameter for the visibility animation AlwaysOn/Off?

I’d like the object and its unneeded animations to be disabled and not logging unfindable tags. I think I’m not getting an error in this example as the tag is in the PLC but will never have a value.

Nothing in the View SE log but there are messages in KEPServeEX.

The problem I have with using a memory tag is that the global object parameters are concatenated. So I can’t just put a system tag in the AMPs global object parameter as it will prefix the PLC and its topic. Maybe I can use an expression but a disable attribute would be nice.

I'm not sure I understand. You'd have to use a separate global object parameter for each thing you wanted visible or invisible. Something like this on your global object definition:

...and then something like this on each instance of the global object on your main screens:

Say some pumps have Pump AMPs and others don’t.

Somewhere inside the global object is an animation (numeric display) that displays the pump AMPs.

It is now invisible as you’ve set parameter #2 to true/AlwaysOn so you will no longer see that pumps AMPs numeric display.

But… The hidden pump AMPs numeric display is still linked to the Pump1.AMP and you get an error saying that tag don’t exist for this pump. The animation expression is still parsed and you get the error.


The global object I was given has global parameters for many of the pumps tags. So a link on the object is something like {#102#202} with #202 being the Pump Speed part of the tag. So I can’t just use a View SE memory tag as it will still get the KEPServerEX prefix topic added on.

I was able to use a dummy tag "DisGroupObject_A" in KEPServerEX and put that in for #202, it then finds that tag and no errors. I was able to use the string from #202 for the visibility ("#202" == "DisGroupObject_A") so no extra parameters, just the use of the dummy tag now hides numeric display.

Ah, I'm following you now.


I had a similar thing with my valve AOI's. A double acting valve has both an open and a close command, but a spring-return valve only has an open command, and closes when that is removed. I wanted to use the same faceplate for double acting and spring return valves, but obviously the "close" command isn't there on the single acting. My solution was to add the additional tags to the spring-return valve AOI as local parameters, and then just not use them anywhere. That way the HMI can find them, even if they're redundant, so the faceplate works just fine. Obviously it makes the data type slightly larger, which could be considered wasteful - but these days memory use is less and less of a concern, and the "waste" of a couple of extra bits here and there seems much less wasteful than having to generate and maintain two separate faceplates for otherwise identical objects.

ASF said:

My solution was to add the additional tags to the spring-return valve AOI as local parameters, and then just not use them anywhere. That way the HMI can find them, even if they're redundant, so the faceplate works just fine. Obviously it makes the data type slightly larger, which could be considered wasteful - but these days memory use is less and less of a concern, and the "waste" of a couple of extra bits here and there seems much less wasteful than having to generate and maintain two separate faceplates for otherwise identical objects.

Click to expand...

That's what I do. Add all the tags that are needed (for the global object) into the UDT; even if you are not using them in the PLC.

ASF said:

I'm not sure I understand. You'd have to use a separate global object parameter for each thing you wanted visible or invisible. Something like this on your global object definition:

Click to expand...

Small detail, but it could matter.
It's best to use parameter numbers that start with #100.

The problem is if you use both display parameters and global object parameters. By starting your global object parameters at #100 it is unlikely that they will ever conflict with the display parameters.

Ex. The display you load is loaded with parameters #1, #2, #3.
AND you also use a global object on that display with has its G.O. parameters as #1, #2, #3. That would not work the way you want it to.

That's an excellent point, and one that I've not come across/considered before. Thanks for the tip, I'll be sure to use it in future!

Wow, Canadians and Australians being so helpful. My great grandma was sure wrong about you guys.

I’ve also taken to grouping types of variables together. Like #100+ Tag prefix/Text, #200 Analogs, #300 discretes and so on. Helps (a little) keeping variables from many different objects strait.