AB Nested AOIs and FactoryTalk View (HMI)

This thread is about setting up a project (using the Allen-Bradley ControlLogix class CPU) with 'nested' code blocks.

The questions are:

1. Is it a good idea or generally accepted way of doing things?

2. How to interface nested AOIs from FactoryTalk View HMI?

3. Where to define 'SCADA only' signals in an A-B PLC?

Some background: we would like to structure a new PLC program in such a way that:
- it reuses code (no copy/pasted code throughout the program)
- its structure resembles an object tree (OOP style if you like)

I found that the so called "Add On Instructions" (AOIs) at least allow code reuse.

The trick then seems to be how to use these in combination with Rockwell FT View HMI;
probably using the "Global Object" graphical counterpart.

All good, but now I'd like to go a step further:

What about nested AOIs?

Consider an AOI that implements an electric motor:
why not let this block contain its own timers, alarms and HMI interface variables?

So in theory - by instantiating this electric motor AOI - that would automatically result in the following tag tree:

Motor (the motor AOI itself)
...
Motor.ScadaCmd (example of a contained HMI command boolean)
...
Motor.TempAlarm (a nested alarm AOI)
...
Motor.StartTimer (a nested timer object - possibly a built-in PLC function)
...
Etc.

Found that these AOIs can be nested in the PLC just fine.
But the HMI only 'sees' the Motor AOI itself!

That's why I am not sure that nested AOIs are a generally accepted way of doing things.
I'd expected to see the alarm and timer sub blocks in the HMI tag tree.

Right now the contained ('child') AOI is defined as a Local variable in its AOI 'parent'.
But Local variables are never visible in the HMI tag tree (even with their External Access column set to "Read/Write").
This is probably by convention.

What seems to work:
- accessing the 'parent' AOI's parameters (IN/OUT and INOUT) from HMI

What doesn't seem to work:
- accessing any Local variable from the 'parent' AOI (although it could be that they are acessible, yet invisible)
- accessing any parameter or local var from the 'child' AOI

And then I found this, saying it's not possible:

https://support.inductiveautomation...-the-controllogix-and-compactlogix-processors


Posted by Peggie Wong on 09/05/2014 11:28 AM:

Reading and browsing Add On Instructions (AOI) within Add On Instructions of the ControlLogix and CompactLogix processors

Reading Add On Instructions (AOI) within Add On Instructions is not supported by A-B. In fact, tags with this architecture cannot be browsed in RSLogix and RSLinx.

Alias type of tags can be used to read and write to members inside of AOI that reside inside of another AOI.

Click to expand...

I have done nested AOI's and managed to access them in IFix, but I have never tried with Factorytalk.

The link you have supplied refers to Ignition and not factorytalk.

If I get 5 minutes I'll test it.

Cheers

Mark

Don't confuse nested UDTs w/nested AOIs.

The proposed functions can all be achieved within a single AOI. We've done this very thing were a motor has a SCADA command and Status tag, alarm tags, on/off delay timers, configurations for VSD/non-VSD control and manual control. Our device pop ups on SCADA directly correlate to the device function of the AOI (never have nested AOIs).

In my opinion nested AOIs are not intuitive, unless you're calling a very basic AOI that simply needs to perform a logic function only such as a calculation.

I think you are over-thinking it. Keep the device a single AOI for each device type you want to create, then in SCADA create the device pop-up to match the functionality of the device AOI.

A motor could indeed be implemented as one big AOI.
I agree that I might be over-thinking the problem.

But this was just a simple example.

Let's say we expand the motor AOI with a feature that allows overruling certain in- an outputs.

In a typical use case, the user would first click on the motor symbol in SCADA to get the corresponding motor popup.
Next, he/she would click the appropriate motor in- or output to overrule.
A *second* popup then shows having the actual overrule buttons for that signal.
The buttons there allow forcing that specific motor signal to a different value.

An AOI could implement the overrule logic. I'd then put several instances of these inside the motor block.

But I will not be able to access them from SCADA due to the apparent aforementioned limitation.

Instead..
1. I would have to repeat (copy the overrule logic) several times inside the motor AOI?
2. I would have to call the overrule AOI outside the motor block
3. Use UDTs?
4. ?

Case 2 even causes extra problems for the SCADA designer.
Because the tag names are not fixed now and outside the motor (tag tree) path.

MarkNightingale said:

I have done nested AOI's and managed to access them in IFix, but I have never tried with Factorytalk.

If I get 5 minutes I'll test it.

Click to expand...

How did you manage to access them externally (with any SCADA)?

Because it says in the documentation that Local tags are not available outside the AOI.

Or is it a matter of knowing the fully qualified tag path even though the tag browser is hiding the names? ;-)

edw1983 said:

A motor could indeed be implemented as one big AOI.
I agree that I might be over-thinking the problem.

But this was just a simple example.

Let's say we expand the motor AOI with a feature that allows overruling certain in- an outputs.

In a typical use case, the user would first click on the motor symbol in SCADA to get the corresponding motor popup.
Next, he/she would click the appropriate motor in- or output to overrule.
A *second* popup then shows having the actual overrule buttons for that signal.
The buttons there allow forcing that specific motor signal to a different value.

An AOI could implement the overrule logic. I'd then put several instances of these inside the motor block.

But I will not be able to access them from SCADA due to the apparent aforementioned limitation.

Instead..
1. I would have to repeat (copy the overrule logic) several times inside the motor AOI?
2. I would have to call the overrule AOI outside the motor block
3. Use UDTs?
4. ?

Case 2 even causes extra problems for the SCADA designer.
Because the tag names are not fixed now and outside the motor (tag tree) path.

Click to expand...

Again, I would put your override logic into the AOI itself. I assume you mean you want to manually operate a motor to start/stop, run forward/reverse, and adjust the speed. Keep it all in the single AOI logic. Don't create a second AOI for that purpose.

A UDT is created whenever you create an AOI. Every AOI has an associated UDT.

Calling a second popup on your display really makes no difference (although I prefer to keep all functions on a single pop up), however makes it messy as you typically will have a single popup and pass a parameter to it for the instance of the device you want to control.

Hi edw1983,

This is not intended to try and change the direction you are currently pursuing, just give you a little more food for thought - as it sounds as though you are still in the concept stage of your project!

Have you looked at Rockwell's PlantPax platform? Not suggesting you go ahead and implement it, but maybe look at what features and functionality it gives. We've recently done 3 large systems all using the PlantPax objects. There is a learning curve with it, but you do end up with a very powerful interface for your project. It has pre-designed faceplates, which are actually multi-layered/multi-tabbed and provide all sorts of operator/engineer/bypass functions, alarm setup, simulation etc. Even if you take a look at some of the functions and blocks (all AOIs/UDTs and faceplates are provided in sample projects), you may be able to take the essence of what it provides and give you some useful prompts or ideas how to represent your particular interface!

See link below...

http://www.rockwellautomation.com/g...ess-solutions/plantpax-capabilities.page#tab1

Here's a link to some screen shots of one of the motors used in one of our projects.

https://www.dropbox.com/sh/551vqfdnersbwqd/AAAnBJ0Jn9MToiJWfXubr9Pja?dl=0

Hope this helps.

Regards,

Rob

I've never done nested AOI's and tried to link it to FTView, but...

If you nest an AOI, the nested AOI will be a Local Parameter of the "main" AOI (as opposed to an Input or an Output).

Local Parameters are never "browseable" by FTView - i.e., you can't open up your tag browser and select it.

But...

You can still manually address them. Let's say I have an AOI called Motor1, with a Local Parameter called "RunOnTime", of type DINT. My FTView tag browser will find Motor1, and all it's Input and Output parameters, but not RunOnTime. However, I can still manually address Motor1.RunOnTime, and it will display correctly on a PanelView Plus or other FTView device at runtime. IF - and ONLY if - I first set the RunOnTime external access parameter to something other than "None", which it is set to by default. I must set it to Read Only or Read/Write, and then FTView can access it.

I've never taken it any further than that, so I can't vouch for what I'm about to say next, but I think it's worth a try:

If my Local Parameter was RunOnTimer of type TIMER, I *think* that in the same manner I would be able to manually address Motor1.RunOnTimer.PRE or Motor1.RunOnTimer.ACC or Motor1.RunOnTimer.DN

If this is the case, I see no reason that I couldn't do the same thing with nested AOI's:

Motor1.LimitStart.Active (where Motor 1 is the "main" AOI, LimitStart is the nested AOI, and Active is a BOOL tag of the nested LimitStart AOI.

Obviously, if this works at all, you'll need to set external access to at least Read Only for each nested AOI and it's elements.

Give it a try and let me know how it goes!

Kidblue said:

Hi edw1983,

This is not intended to try and change the direction you are currently pursuing, just give you a little more food for thought - as it sounds as though you are still in the concept stage of your project!

Have you looked at Rockwell's PlantPax platform?

Click to expand...

No, I didn't know about that platform. Thanks, it looks promising!

And yes, still in the concept stage. I'd rather spend a few days figuring out how to set up the project rather than just start programming immediately.

ASF said:

If you nest an AOI, the nested AOI will be a Local Parameter of the "main" AOI (as opposed to an Input or an Output).

Local Parameters are never "browseable" by FTView - i.e., you can't open up your tag browser and select it.

But... You can still manually address them.

Click to expand...

Exactly what we found (they are not browseable). But sounds hopeful that we can *still* access them regardless (we didn't try that yet)!

Obviously, if this works at all, you'll need to set external access to at least Read Only for each nested AOI and it's elements.

Give it a try and let me know how it goes!

Click to expand...

Ah, so the Local variable really isn't that local, having an External Access setting! It compares to the Siemens STAT variable section inside a FUNCTION_BLOCK (also often used to interface with SCADA).

Although I find it is quite sneaky to use Local OR STAT(IC) variables as SCADA-interface, so far it seems there is no other practical way.

We will try it today post our findings.

edw1983 said:

Ah, so the Local variable really isn't that local, having an External Access setting!

Click to expand...

Well, it is still Local in the sense that you can't address it externally in the PLC code.

In my example above, while a HMI might be able to look at (and even write to) Motor1.LimitStart.Active, you can't write logic in the PLC to access this bit, no matter what the access type.

I'd be very interested to know how it goes using nested AOI's, I'll watch this space!

We have found that nested AOIs indeed work with FactoryTalk View.
So far, so good.

Next, we discovered the Device Alarms feature.
The CL 5000 series in combination with FactoryTalk View SE provides built-in ALMD and ALMA instructions that allow defining 'tagless' alarms inside the PLC.
I call them tagless because FT View SE automatically recognizes these alarms once you have downloaded them into the PLC.
So no alarm tag to be defined inside SCADA etc. Very nice!

With nesting this could mean, say, that alarms belonging to a motor typical would not only be automatically created,
but also automagically appear on SCADA after a PLC download!

Unfortunately, nesting these ALMD and ALMA instructions does not fully work.

There are a number of problems:

1)
You can't define data type ALARM_DIGITAL (needed for ALMD) as a LOCAL variable inside an AOI.

It can be defined as INOUT parameter though.
And your code works, but you cannot open the properties dialog for the nested ALMD/ALMA call.

I think it's because the properties dialog then can't locate the data for the actual variable connected to the INOUT parameter.
The designer might not know for which call-up path you want to edit the properties.

You see, an AOI can be called 0-N times, perhaps each time with a different ALARM_DIGITAL variable (via the INOUT parameter).
So which ALARM_DIGITAL variable is the designer supposed to edit if you are editing the AOI?
It would have to list all the calls to the AOI first and then ask you which one you meant?
The editor is not that clever.

So you will have to go back to the (main program?) task to edit the ALARM_DIGITAL variable there.
You can do that by temporarily creating an ALMD call with that specific ALARM_DIGITAL based variable.
Then you'd open the properties dialog there and modify the settings.
Finally, you'd delete the extra ALMD call again.

We tried that - and it works - but of course that's unacceptable...

2)
You will have to define the alarm instance vars (of type ALARM_DIGITAL) outside the AOI, this defeats the nesting scheme and makes the alarm processing 'flat' again.

3)
FT View will show the path to the ALARM_DIGITAL value in its alarm summary screen, not the call up path to the AOI-instance of interest

edw1983 said:

I think it's because the properties dialog then can't locate the data for the actual variable connected to the INOUT parameter.

Click to expand...

Just discovered that there is a DATA CONTEXT drop down list in the Logix Designer editor. It seems to know the data used for the different call-up paths that exist in the application!

When I select the appropriate variable, the properties dialog works again.