MSG Instruction Inside AOI

[Astleas]

Hi all. Long time lurker, first time poster.

I'm working on a project to write a program to monitor the diagnostics data in a number of Stratix switches. A lot of the parameters I need to see (e.g. temperature, MAC addresses) are only available through explicit messaging, which is fine enough. Each parameter has the class/instance/attribute information listed in the EDS file, so configuring the messages is simple.

My problem lies in the magnitude of the task. There needs to be a separate message for every parameter of interest, not to mention the fact that some of those parameters exist for every port on the switch. Configuring all the messages for one switch is doable, but doing this for every switch the program needs to monitor is untenable.

Ideally, I would have an AOI that handles all the messaging internally. The message class, instance, and attribute are identical for a given parameter across every switch, so all this AOI would need is a reference to a particular switch and then it could spit out the parameters for that particular switch. Develop the AOI, copy it onto a new rung for every switch, change the reference for each one, and I'd be done. From my own tests and based on all the forum posts I've read thus far, however, messaging can't really be done within an AOI - at least not without having to configure that message externally in the routine where the AOI is being called (and if I had to do that for every message, it would defeat the purpose.)

Is there any way to get something close to that ideal solution? Anything I'm missing? I'm using version 32 of Logix, working with an L85, so I'm hoping something might have changed in between those old forum posts and now that might make what I'm looking for possible.

 

[DBLD99]

Yeah I wouldn't do it in an AOI.

Have a routine that will be indirect and have it cycle through all the messaging. With an Index. Make a UDT that will hold all the members you need use an array that will hold the Enable,Message_Config,Read/Write Duration Timers,Comm Delay, Read/Write Failure Attributes etc... that will be indirect.

I do something similar when reading a lot of data from remote sites. This way all the messages are staged as well and not all firing at once.

 

[paulB]

We are using Rockwell PowerFlex 525 Faceplate AOI in our machines. This AOI has logic that sends message to the VFD to retrieve last fault code. It works pretty much as you have described. Machine has around 40 VFDs. AOI is called that many times and same number tags of message type are configured as controller tags.

PaulB.

 

[janner_10]

We are using Rockwell PowerFlex 525 Faceplate AOI in our machines. This AOI has logic that sends message to the VFD to retrieve last fault code. It works pretty much as you have described. Machine has around 40 VFDs. AOI is called that many times and same number tags of message type are configured as controller tags.

PaulB.

You don't a MSG for that, just read in the output array.

 

[Contr_Conn]

There is a Rockwell supplied AOI for Stratix Switches that already does what you are trying to do. It comes with HMI faceplates too.
Search in PCDC under Network Device Library. One AOI is covering all modern Stratix platforms.

 

[Contr_Conn]

To answer your initial question, MSG tag is always InOut parameter for AOI.
But configuration can be done programmatically inside the AOI.
The only one thing that is not configurable is the Service code.
Therefore, you need to have Get Attribute Single and Get Attribute All messages separately.

Again, my recommendation is to use Rockwell supplied AOI instead. It does all messaging for you.

 

[ASF]

I went down this path a few years back, and Contr_Conn had all the answers then, too.

Here's my thread on the subject for reference.

 

[5618]

As noted by Contr_Conn, the Rockwell AOI already exists. It is made to interface with the PanelView faceplate, but that’s not required.

Noteworthy if you’re using a different HMI: the AOI information is presented to match the pages of the faceplate. Recreate the pages for your HMI. Also, the select buttons in the faceplate are momentary and held for 500mS. I thought that was kinda lame. My HMI latches on the buttons, and they’re unlatched in the PLC.

Here’s a few screenshots from a four Stratix system used with an InTouch HMI that might help with some ideas. I used one HMI Stratix tag and copied parameters to and from whichever Stratix AOI tag is HMI selected. They’re readable but a bit fuzzy from shrinking file size.

 

[theColonel26]

Wait what?

You can call the MSG instruction inside an AOI?



I guess I didn't consider passing the MSG backing tag in with an InOut. I once tried to define it inside an AOI as a local, and Logix Designer told me to *$&@ off.

 

[5618]

Here’s some additional information for anyone who wants to roll your own HMI for the Stratix AOI, and can’t break down the faceplate in FTView. Different pages of the faceplate set Animation_Active to different values. Home pages 1, 2, & 3 set values to 10, 11, & 12. When I open my overview faceplate, I set Animation_Active to 10. That enables all the messaging to get the information for all three pages. 11 & 12 would work the same and don’t do anything extra. I put all three pages of information on my home page.

Network pages 1, 2, & 3 set Animation_Active to 20, 21, & 22. I don’t recall if each number mattered for the messaging for the different pages of detailed port information. I think any of the values enables the needed port messaging. My application uses each value for the corresponding popup.

The cable diagnostics page sets Animation_Active to 30, CIP sync to 40, global alarms to 50, and port alarms to 51. I didn’t develop anything for these in my application.

The port buttons set the Home.Set_Port.Bit[x] corresponding to the port. There are also scroll buttons to set Port_Selector.Set_Port_Up(orDown).

Animation_Active and the port selection bits are from the HMI to the AOI. Information to the HMI or other usage is found in Parameters.Home, Parameters.Port, and more.

Port_Indicator[x] values to match the home faceplate: 0=grey, 1=red, 2=brown, 3=green, repeat for 10 to 13.

In port page 1, Link_Status values: 0=grey/Inactive, 1=green/Active, 2=black/Disabled, 3=red/Alarm.

Stuff on port page 1 I’m not getting into this post: InterfaceFlags for auto-negotiation and duplex indication will need a bit of logic. SmartPort_Number has a bunch of values for different text.

Last thing noted here: port page 2 values have the least significant digit as a separate UDINT[0] tag. Tens place and up of the value is UDINT[1]

 

[Contr_Conn]

I believe that description in the post above is accurate, except it’s done for the orders version of AOI that is not available any longer on the Sample Code site.

Currently posted version on PCDC uses different tag names and the most important moves HMI related tags to the Local Tags. As a result these can’t be accessed programmatically outside of the AOI, as if these would be AOI parameters. There are some workarounds to this as a well.

 

[Astleas]

Thanks for the feedback, everyone.

I took a look at the AOI that Rockwell provides in the Network Device Library, and it appears to be cycling through different classes, instances, and attributes in the same message, similar to what DLBD99 described. Based on Rockwell's instructional video on the faceplate, it looks like this AOI gathers most of the data available in the EDS file.

I see that this data is only available in the "HMI_Parameters" of the AOI which are, as Contr_Conn noted, all local tags. What are my options (if any) for exposing these parameters to the rest of the controller? This particular project does not (yet) require any external HMI; just that the data be available as controller tags for the user to view and to trigger some physical alarms. If I could get those as controller tags and then do the previously described message cycling for any data those tags don't capture, I'd be in pretty good shape.

 

[JeremyM]

You can do three things to retrieve an AOI's local UDT programmatically:

1) Send a message from the controller to itself:

• Message type: CIP Data Table Read
• Source Element: AoInstance.LocalTag (the local tag must be Read/Write or Read-Only)
• Number of Elements: 1
• Destination: Any tag of the same type as AoInstance.LocalTag

2) Create a new parameter (can be Input or Output) in the AOI:

• Alias this parameter to the first element of the nested UDT
• I prefix these parameters with Ptr_ (since it's effectively a pointer)
• Create an OutsideTag of the same type as the local one
• Do a COP(AoInstance.Ptr_LocalTag, OutsideTag, 1)

3) Create an In/Out parameter and COP to it within the AOI.

 

[Contr_Conn]

As JeremyM mentioned, all 3 methods work, however, there are few limitations:
- Methods 2 and 3 work only on unprotected AOIs, but in this case the AOI is code protected.
- Methods 1 and 2 gives you read only mirror copy of HMI_Parameters tags, you will have to use MSG Write command to write data into a specific local tag only.

Also keep in mind that some information in this specific AOI is only available when specific tab is open on the HMI, I don’t remember details, but I am pretty sure it works this way.

If you write your own code, do not send simultaneous messages to Stratix, do one at the time.

And finally, code is protected, but visible, so you can spend few hours retyping it into your own AOI. Not a best solution, but faster than developing something from scratch.

 

[5618]

It’s been a few years since I started using that AOI, so it was conceivable that there was a newer version. Today, I searched PCDC sample code for “stratix” and the 10.00.01 version I have been using with Logix V20 and Studio V32 is the first result. The contained zip file has a date stamp of 8/31/2017 so it seems unchanged since at least then.

There is a link with this to a newer V12 which led me to NetworkDeviceLibrary_v1.04.00.zip. Briefly checking it out, it seems to have extra DLR stuff over V10 that I don’t need. It’s advertised for V30+ and failed to import to V20. Yup, for some disappointment, HMI_Parameters is local with external read/write access. That's unfriendly.

I suspect most of AOI V10 values I've posted will match AOI V12. It’s a continuation of the old AOI, not completely new. I didn’t dig deep.

To complete the V10 AOI information:
InterfaceFlags.01 off = half duplex, on = full duplex

For Autonegotiation indication, these values are the result of InterfaceFlags.02 + InterfaceFlags.03 * 2 + InterfaceFlags.04 * 3:
0 = In Progress
1 = Failed
2 = Duplex Fail
3 = OK
4 = Forced

In port page one, I noticed I have these for port threshold broadcast units after the value, but I get 0 so they don’t appear on the HMI. Added to low priority todo list to investigate.
1 = PPS
2 = %
3 = BPS

Lastly, SmartPort_Number values:
0 = None
1 = Automation Device
2 = Multiport Automation Device
3 = Desktop for Automation
4 = Virtual Desktop for Automation
5 = Switch for Automation
6 = Router for Automation
7 = Phone for Automation
8 = Wireless for Automation
9 = Port Mirroring
10 = User Defined
<0 or >10 = Error