Red Lion - Faceplates

FTView does it a couple of ways, parameter files (ME or SE) and direct tag calling (SE only).


Parameter files works like this...


I have a popup that controls a motor. So it has a start button, a stop button, a reset button, a multistate indicator that shows running/stopped/faulted/auto/manual based on an integer, and a few other things. The motor is controlled by an add-on instruction in the PLC called "Motor_1".


I develop my display. There are two lines of text at the top that are set to display "#1" and "#2".
My start button doesn't act on "Motor_1.StartButton", it works on "#3.StartButton". Likewise, the stop button acts on "#3.StopButton" and the multistate indicator points to {#3.Status}.


Then I create a parameter file that looks like this:
#1=Widget Packaging
#2=Conveyor
#3={[PLC]Motor_1}


At runtime, I click on a button which calls my motor control display, with the parameter file above. The display replaces all instances of #1, #2 and #3 with what's in the parameter file. So when the display pops up, the top two lines which are directed to display #1 and #2 display "Widget Packaging Conveyor". The buttons are now addressed to Motor_1.StartButton and Motor_1.StopButton, and the status display looks at Motor_1.Status.


So now I can create a single display, and call it with literally 500 different motors. That's an overwhelming time saving, especially if I need to add an extra button or an extra value to the status display.



If I didn't have an AOI behind all this, I could still do the same thing, I'd just need more parameters. Instead of being able to go #3.StartButton and #3.StopButton I'd just have to use #3 and #4, and then have the parameter file refer specifically to each individual tag in the PLC instead of pointing at a single tag structure and calling out individual elements. But being able to do it with one tag is a huge benefit - again if I need a small change, I don't have to update 500 parameter files with the additional element, I just have to update the AOI and then call out that additional element from the same #3 placeholder on the popup.


The direct tag reference works the same way, except you don't use a parameter file, you just literally define the parameters as you call the display. So my button code looks something like:
The /T flag means that what comes next are the tags references by the display, separated by commas, in numerical order (#1, #2, #3...).


Even easier again!

keshik said:

This is a maddening feature of Crimson. I asked them about adding proper global objects several years ago and the response was that it was a feature that nobody wanted.

Click to expand...

ASF said:

FTView does it a couple of ways, parameter files (ME or SE) and direct tag calling (SE only).

Click to expand...

Both statements are true.
Sorry ASF, but you'll have to pay up for either Siemens or Rockwell.
If you have a large HMI project, and code re-use for time savings is needed, then those are the only two HMIs that can give you that.


For the customers that Red Lion has (their market), I would agree that nobody wants/needs global objects. Or, at least not a large number.
Crimson was (is) not designed for large HMI projects; it works really well for quick, easy learning on small to medium sized projects.

On the flip side, FTView was specifically designed for large projects (FTView Site Edition) which FTView ME (PanelView Plus) gets the benefit of.
Or, that's a bad thing and makes it complex... one could see it either way.
But, FTView was designed for medium to large HMI projects.

Hi all. This is my first post here, so please go easy...

I felt this is related to this thread, as I was tossing up between purchasing a RedLion and a Weintek (Maple).

I wanted a 3rd party HMI that could use faceplates and indirect addressing. And I found it!
I use RS5000 and Omron Sysmac.

I recently purchased a Weintek MT8150XE.
The programming software EasyBuilder Pro has it's quirks, but it's very usable.
I'm still learning, but I wanted to see if I could get a faceplate working first up.

Although EBPro can import UDTs from RS5000, these can only be directly addressed, which defeats the purpose of the UDT.
EBPro also cannot import Structures (UDTs) from Sysmac, strangely.

EBPro does however have internal addresses which it calls "Index Registers" (16 x 16bit and 16 x 32bit registers), which can be used to indirectly address arrays.

This does however mean that I had to map these array tags to the UDTs/Structures in the PLC program using AOIs/function blocks.

But once setup, I can now use one faceplate for each UDT in RS5000 and one faceplate for each Structure in Sysmac, all from the same HMI/project/window.

In EBPro, you can also setup a "Label Library" which can be used to store your descriptions/names/IDs of your instances and indirectly address these too.
Each entry is limited to 256 "states" which you can indirectly address, but you can have multiple entries, if 256 instances of a UDT is not enough.


Here's how I set it up:

HMI/PLC tags:
Motor_HMI_StartPB - BOOL[512]
Motor_HMI_StopPB - BOOL[512]
Motor_HMI_Running - BOOL[512]
Motor_HMI_Status - DINT[512]

PLC UDT tags:
StartPB - BOOL
StopPB - BOOL
Running - BOOL
Status - DINT

Mapping:

Motor_HMI_StartPB[1] > 111M1.StartPB
Motor_HMI_StopPB[1] > 111M1.StopPB
111M1.Run > Motor_HMI_Running[1]
111M1.Status > Motor_HMI_Status[1]

Motor_HMI_StartPB[2] > 112M1.StartPB
Motor_HMI_StopPB[2] > 112M1.StopPB
112M1.Run > Motor_HMI_Running[2]
112M1.Status > Motor_HMI_Status[2]


In EBPro, I did import a UDT array, however the Index Register only seems to work when the array index is at the end of the address.
Motor_HMI[1].StartPB cannot be indirectly addressed.
Motor_HMI.StartPB[0] can be indirectly addressed.

I hope this helps someone.
(Should I post this on a new thread also?)

mesl said:

I hope this helps someone.
(Should I post this on a new thread also?)

Click to expand...

Welcome to the forum! Yes, you should post this into a new thread.
Something like "Weintek / Maple Systems EBPro faceplate"
This thread is about Red Lion faceplates, or the attempt at it.

What you did with EBPro is clever; I do like their index registers.
But in this case, for the OP, I would still choose Red Lion.

You have to create all the tags in either EBPro or Crimson, which defeats the goal of the OP question.
The Widgets and tag database in Red Lion would give you more flexibility. Yes, you would have to create a new popup for every valve. But there are some advantages:

• don't need any PLC changes
• the widget/popup code is easier to manage, change, or pass on to the next person.
• could open more than one popup at a time

anyway, good Weintek post. Just put it into a new thread so people can find it.