Making the Parameter file a variable on Goto Display Button

I'm probably in the realm of 'Nope not Possible" here but here's my issue.

First things first. FactoryTalk View ME V9.0. I'm new to the company (1st month) but not to Rockwell and Panelviews. This is the first HMI I've had to do for them and there are some abnormalities from their basic format. Yeah!!

Also I am working with a standard company template default program and am limited on what changes I can make for functionality and appearance.

I am working on a project with 15 "Zones". Each zone has 3 troubleshooting/ information screens. Normally we have 3-5 zones and they make 3 screens for each zone. I do not want to make 45 screens where I really only need 3. Just one hopefully solvable issue holding things up.

I am using a single zone screen and passing the parameter file I want to use based on which one of the 15 zones you select to view. That's all good. No issues there.

The first screen is the Zone screen. From here you can access the Zone Operating Fault screen and the Zone Motor Fault screen via Goto Display buttons.

I have a separate screen for each of the Faults and Motor Faults displays.

Now I know it's possible to make the display variable for the buttons but I don't need or want to do that. I want the displays opened from the Faults button or Motor Faults button to be the same each time regardless of which zone I'm in.

What I want to do is vary the parameter file being opened up for the screen based on which zone I'm in.

So on the Goto Display button properties is it possible to use a variable in the Parameter File text field?

For example in my parameter file for Zone 1 I could create a variable of say 17. It would look like this.

17=Zone1MotorFaults

In the Parameter File text field of the Goto Display button I would put {#17}.

Not assuming this would work but does anyone have experience with this.

I know I could have 15 goto display buttons for each and make them visible based on a variable but I don't like that solution.

Thoughts?

I guess why not just try it?

It's been awhile, so can't say for sure.

Yeah that's an option. I'll do that and report back.

The following thread discusses similar capability, and may offer options to accomplish what you describe.

http://www.plctalk.net/qanda/showthread.php?t=115037

Well I just figured I'd report back here.

Creating a parameter in the parameter file and trying to use that parameter to assign the parameter file for the Goto display button did not work. So unless someone else knows of a solution I'll be making 15 zone screens, Zone motor screens and 15 faults screens.

Yeah fun.

Also does anyone find it odd the AB made the display variable but not the parameter file? Maybe it's just me?

Maybe make 2 screens.

Use an input field to select 0 - 15. Then pass that number as a parameter to fill the 2 diagnostic screens with correct data.

Rob... said:

Maybe make 2 screens.

Use an input field to select 0 - 15. Then pass that number as a parameter to fill the 2 diagnostic screens with correct data.

Click to expand...

I was all set to do that but there's another issue. One of the called up screens has a Goto display for each item on that screen that calls up a parameter file for each item as selected.

So I would again need to be able to vary the parameter files selected on each of these buttons. A parameter list selector off screen would be a much more efficient way to do this but I didn't write the program and it is not structured in a way that allows the use of a parameter list in this application.

I may just create a udt for collecting the info and then submit it for an approved change so a parameter list can be used. It's messy otherwise. I was hoping there was a simpler solution based on the structure already in place.

Again this is an unusual scenario for us.

It's not clear how the application initially opens up an individual "zone" display (e.g., 15 different GoTo display buttons, drop-down selection, etc.). Anyway, if the processor can determine which zone is displayed, it can put the fault and diagnostic data for that zone into a fixed set of tags always referenced by the fault and diagnostic displays. One way to do this is with the piloted list selector "hack" referenced by the link in post #4 of this thread.

Mispeld said:

It's not clear how the application initially opens up an individual "zone" display (e.g., 15 different GoTo display buttons, drop-down selection, etc.). Anyway, if the processor can determine which zone is displayed, it can put the fault and diagnostic data for that zone into a fixed set of tags always referenced by the fault and diagnostic displays. One way to do this is with the piloted list selector "hack" referenced by the link in post #4 of this thread.

Click to expand...

The individual zone displays are opened from a Goto display button on the main screen. What they currently have in place is a series of screens being accessed from inside another screen which then has more screens being accessed from inside that screen which then has yet another group of screens being accessed inside that screen. Not very efficient IMO.

As far as using a piloted list selector, yes that's what I was referring to when I suggested using a parameter list selector (My bad) off screen. I've used this in the past but I created the PLC program structure to support it up front. Already created an emulate version of the program and will get to the bottom of it from here.

Thanks for the advice/input so far. If I have any breakthroughs I'll report back again.

Save a backup of the hmi first, the pv may not have enough memory.

just a suggestion,
make 3 screens without the tags.
copy them and then do the edits.
I would try to compile the program after making the copies.
yes, lots of errors, but you will also find out about the memory capabilities.

james

An option for 17 screens instead of 45: create 15 unique, and almost identical zone displays. Assign each zone display a different display number, which can be monitored by the PLC. You could still use the parameter to populate the fields (making it easier to make the 14 copies from a base screen). The processor would use the display number to determine which data goes on screens 16 (e.g., fault) and 17 (e.g., diagnostics) in the same way as suggested by the list selector. Not sure if it helps since this is not that much different than the list selector approach.

Mispeld said:

Not sure if it helps since this is not that much different than the list selector approach.

Click to expand...

Though, this allows you to have 15 different Fault and Diagnostic buttons (one pair per unique zone display), each of which could pass the appropriate zone-specific parameter to fault and diagnostic screens. I think this avoids having the processor monitor the display number and/or list selector tag in order to move data around.