Hi, Is there a way to edit a Type property from the VT HMI? Some users will not have access to the Tag Browser but may be required to change IP address which is set up as a property of the Site Type. I tried several methods to set up a Linked Tag Widget but have been unsuccessful.

I'm thinking that I may have to script it somehow but want to know if I'm missing something before I go down that path too far.

Your help is greatly appreciated. Thank you in advance!

Check out the following video tutorials and let us know if that helps: https://youtu.be/MksZUVjyO58

Thanks Dave,

This issue is slightly trickier than what those five videos demonstrate, I think. Let's say the tank type has a tank volume parameter that was set at 200. One day the tank is replaced with a tank whose volume is 500. How can the user change the tank volume parameter without direct access to the tag browser? In my case, it is an IP address.

I did manage to script it using the SimpleOpChange function.

You can always set up any number of application-level properties (System level) which a user can update using the property widget. You can call any system-level property using '\PropertyName'. This scheme can also be a great way to store a local constant or variable.

The downside of the application property as "memory tags" is that they only serve the function of being editable with the Edit Property widget.

They aren't logged as tags like everything else, or historized, can't alarm (unless creating additional tags to point to them), can't be referenced by a multi-write tag, can't be used in the type system, and are impossible to maintain except by an integrator. They also can't use the Numerical Entry widget.

Which leaves the only valid option of using up your tag license with analog control tags that aren't pointed to a driver. Which, because they are control tags, still can't be logged or alarmed on, so you still also need to create calculation tags to reference them.

So if you want to allow operators to choose the priority of an alarm, for instance, outside of the tag browser (on the screen) you require 2 licensed tags for every alarm point. Seems to encourage license-thwarting practices like bit-packing an analog tag, IMO.

The point of the property isn't to be a "memory tag". It's to allow an authorized operator to change a specific property of your Analog Status without needing Tag Modification privileges, which was the question you asked.

Perhaps an example would help:
Let's call the application property TankAVolume. Set it to 200.
In your type, you have a Volume parameter. For Tank A, right-click on that parameter and select Add Parameter Expression.
The expression is \Code\TankAVolume
Deselect the "Optimize to only evaluate at tag initialization" option.
(Careful! The tag and all of its descendents will restart every time a new value shows up. Most parameter expressions should be optimized.)
Save the tag.

You'll certainly want an Edit Property widget, which you'll place on a protected page. That keeps the unauthorized users from changing the volume.

You can do the same with the IP address of a port, etc.

I don't see where you need an Analog Control or a Calc tag to solve the problem as originally stated.

Andrew, I definitely don't disagree that the property approach will work; we've thought about using it to get around license limits before for building memory tags, but I don't think it's a maintainable solution if you had for instance, 1000 objects with 5 properties each.

I think the analog control tag without an IO driver is better in every way (except for eating up licensed tag count) as:

• it integrates with the type system, so you only need to build it for one object
• it's easier to build widgets for it because it works with the numerical entry box, control dials, etc. instead of just the "Edit Property" box
• changes are logged like other tags in the system and what user did them
• tag level security so there is no need to create a popup to control access to the control widgets
• can work with the multi-write tag, which is extremely important for big systems

Using this approach we've built a full roster contact scheduling system, integration with recipe management and storage systems, alarm and tag configuration at the screen level for fine tuned control (ex. so operators can change alarm priorities, setpoints, and delays without having access to Tag Modification privilege).