System Platform Advice?

[JeremyAdair87]

Hello, I'm struggling to learn something on Wonderware, and the distributors are taking days to get through the email chains. I was hoping for some advice.

I have a PLC conversion I'm working on. We are adding in AOIs to a line that has a few hundered heating zones, and my manager wants more of object oriented programming. He also wants 9000 tags or so grouped into new UDTs(this is one line, but they have 40 almost identical lines they are old legacy PLCs that they plan to upgrade). I tried KISS, but I understand why he is going the route he is. The machine isn't complex, its just a large continuous process, and they want their operators to stop bypassing thermocouples, and telling heaters to run with online edits. They are playing with fire, and bypassing PIDs in a bad way. The heaters can build pressure and bend steel, damaging the machine/bystander.

All of their screens are in intouch HMI/windowmaker, and my manager has purchased system platform. The galaxy is brand new. I've done a DBdump from Intouch Application manager. I tested updating tag names, and I'm confident I can Update the new tags to the old screens over in windowmaker. I'm pretty sure I can get the machine running regardless.

My manager has taken training on Application Manager, and Intouch HMI. I assume (i need feedback here) that he has mixed the training between Application Manager, and Intouch HMI.

When I'm going through his training manuals from Aveva, It looks like the Intouch App gets pulled into the galaxy with an Intouch app viewer, and then there isn't a lot to do inside the galaxy aside from deploying the Intouch HMI application. My manager is assuming that the System Platform Plant Model/Templates/objects/IO created in the galaxy can be used in the Intouch HMI/Windowmaker App. From what I'm reading I think there is an error here.

I'm Assuming that the templates/objects/IOdevicemapping in system platform's galaxy are for Intouch OMI. I'm new to system platform, but I know the old Intouch stuff. I'm also assuming that most of the object oriented programming that I'm seeing in the Application Manager training manuals is the route that my manager would prefer. There is an Item called Autobuild which can take AB/Siemens programs, and create IO mapping for me. I organized my AOIs the same way I would for Ignition. Each device has an AOI. It looks easy enough to maybe turn several screens from windowmaker into objects in system platform, and attach the IO mapping created by autobuild. At the same time I checked his licensing and the server has a ton of stuff of Intouch HMI, but I'm not seeing anything for Intouch OMI.

Can I get any advice on my problem before I talk to my manager? Theres a lot a could be completely wrong on here, and I'm about 15 manuals deep, and stretched a little thin on this one.

 

[ynpmoose]

You are headed in the right direction. When you talk about AutoBuild, that is supported for Control/CompactLogix and Siemens S7-1200/1500 (symbolic). It can connect to the PLC online or take an offline tag file. If you search "AVEVA Autobuild" on YouTube there a a few videos that will show you how it works. It will load in your tag structure and you can choose which sections you want build into objects and which parts you do not. It will create all the galaxy objects and tag attributes in a structure matching the PLC . You do not have to use AutoBuild for what you are doing, but it can be a huge timesaver of a project with goals such as yours.

Your Manager is right about the object oriented capabilities of Application Server. Objects in a galaxy can hold IO and memory tags, scripts, have history/alarms enabled, and contain associated graphics. This can all be templatized so tags and graphics only need to be designed once, but can be tweaked at the instance level if needed. The tags or graphics can be used in InTouch Managed Applications (View apps hosted and designed from the ArchestrA IDE like you want to use) or in OMI. To use the tags in the View apps, you can either put those tags in object or general graphics, or you can configure an Access Name (like you are probably used to) to point to the galaxy object attributes. This Access Name route is the path you likely want to go, at least for now, so you don't have to reengineer any of your graphics. You'll just need to point your tags to their new object.attribute references via the Galaxy Access Name.

From a licensing perspective, you will need Platforms, View Engines, and View Apps deployed to your HMI nodes, so your distributor can help you navigate that if your current licensing does not cover this architecture.