Pros and Cons for the use of Parameter files in FTView SE

I am feeling frustrated with the use of parameter files in FTV SE HMI applications. I feel they have their place, but sometimes just duplicating a screen and changing the tag names would be easier and more straightforward from a maintenance and troubleshooting standpoint for the customers. Any thoughts one way or the other?

rcrumjr said:

but sometimes just duplicating a screen and changing the tag names would be easier and more straightforward from a maintenance and troubleshooting standpoint for the customers.

Click to expand...

No, well, perhaps if it's something unique and basic maybe. But you now have copy/paste, find/replace errors and potential discontinuity assuming changes happen to one and have to get distributed out to others.

Parameter Files/Indirection, whatever you want to call it are fundamentals of control systems and not very difficult to understand.

Or course, poor implementation...

FTView SE is licensed on a "per screen" basis. So duplicating screens and using find/replace is an expensive way to go.

I'd investigate calling the tags directly using the /T flag, instead of calling parameter files with the /P flag. It depends on the application, of course, but it can definitely be a much better way forward.

A good place to use it would be on a drive or a valve control popup. If you can encapsulate everything on the screen into one AOI or UDT (and you really should be able to, for a drive or a valve), then you literally just have to call one tag at runtime, and address everything on your display as "#1.StartButton" and "#1.FailToOpenAlarm" and so on.

A no-so-good place to use this might be if you're looking at an overview of a whole machine, or three whole machines. In that case, there might be so many different tags on the page that it might be much easier to follow if you can open a parameter file to see the list of what's going on, instead of trying to follow 50-60 tags in the dialog box you use to call the display.

The other thing to consider is how often you make changes, and whether those changes are universal or not. If you start finding yourself having to do all sorts of tricks to make certain elements on the page visible or invisible depending on which parameter file you're calling, because there are more and more differences between the systems, you might be better off switching to one display for each application, instead of parameter files. But on the other hand, if you're always making the same change to every system, it makes a lot more sense to only have to change it on one display, and have it automatically replicate across all the others. Less chance of an error, and less time and effort to test your edits.

All depends on the application.