Developing an implementation for a new Green Field, about 25 clients, with maybe 8 different projects in the sense of delineation of area control (remote tank farm vs inside processing vs material handling vs packaging).
I'm of the opinion that smaller, streamlined projects that are specific to the area for safety reasons (alarm acknowledging, local controls, etc) is the better way for the plant to manage and may have performance benefits as well. Historically, that's how we've managed with Wonderware and FTSE.
One of the integrators I'm working with wants to create ONE big project with every possible screen, menu navigation, etc, and manage presentation of area control through scripting, exposure of menus, etc. Their reasoning is they only have to have one template, one popup window, etc. instead of sharing them across projects.
To me, importing or inheriting templates is trivial across projects and not necessarily a reason to implement in this manner. After we leave, I think it would also be easier for non fluent ignition plant personnel to maintain, add a simple control, etc., if the projects were smaller and not so script laden to manage area control. But what I'm really wondering, is there any performance advantage either way? One big project, or compartmentalized projects?
Depends on what the needs are for clients per site, and historian needs etc.
Sounds like an Ignition Edge gateway per site, connected to a central server is not a bad option, especially if keeping historical data and local control are important across remote comms.
I'm with you: use inheritance to share resources, use separate leaf projects (likely with their own IdP settings) to separate access.
I don't know of any performance issues to either approach. One big project would be a maintenance and development nightmare, IMNSHO. (Which wouldn't bother an unscrupulous integrator--setting up future billables.)
Looking more at the maintenance/ease of updating side, how would you handle multiple machines in the same area that are 90% similar with small differences, such as different numbers of I/O points or some with certain functionality that the others might not have?
Would you again follow the logic of an inheritable project with all the matching logic/functionality and then individual projects for each machine that have the specifics?
If there are access issues, I'd almost certainly use separate projects. If the differences could be easily detected in the tag structure, and weren't too substantial, I'd probably use "chameleon" views that hide/show the varying parts.
(The latter is only practical if you are consistently using tag path view parameters to drive indirection, relying on consistent tag names, without relying on specific UDT types. And you should, of course.)
NB if this is Vision you can use system.util.retarget to seamlessly switch between projects if that's a need that ever arises. It's somewhat harder to do so in Perspective due to the nature of IdPs.
If you only have a few screens per area....I'd be more inclined to just put it in one project also.
If tags, users, etc are all shared, that's what the folder structure is for. Organize windows by area at a minimum or break them down more if needed.
Put tags in folders like site, area, etc. On all my projects, I break everything down to at a minimum on a tag level so each view/window has its own folder of tags (you can have folders inside a window folder, but at a minimum I have a folder for every main view/window) that's nested of course in area folders. This makes the organization really easy to find things, plus I use that organization to have a search function on the HMI that does a tag search then allows them to automatically navigate to the screen that tag is on and I highlight/flash it for a few seconds. This also works with my alarm banner so they can double-click an alarm and it takes them to the relevant screen and highlights the graphic/symbol for the alarmed tag.
I organize tags by providers and functions. Thats important for tagpath construction in templates and popups. Most of my projects are for larger areas of process with 40 to 50 screens covering an area, and a tag often appears on multiple screens, so i would not want multiple instances of the same tag in that instance. Novel approach you have and i could see it beneficial on smaller compartmentalized applications.
In our case (large gas plants), each process area takes a few screens, but we try to not show tags on multiple pages unless necessary, and in that case there's a main window that the tag is also organized under in the tag browser, then the other screen/window just uses the same tag (no multiple/duplicated tags for anything). All of my tags use UDTs that are organized by OPCServer/Driver/Company/(Function or Equipment) this way I can find UDTs that I need easily, but keep tag organization and windows/folders towards a more ISA-95 standard as close as possible for our process.
This is a great idea. I am working on implementing the double-click on the alarm status table. I have grouped the tags in folders and the folders have the same name as my views. Then I am parsing out the name of the view from the alarm event source tag then using that to navigate to the view. Is this on the right track?
Exactly! I do have an extra UDT tag in each folder named Area that I use to keep things relevant to that folder, like alarm summary info, and a WindowName tag that way my folders don't have to match my window names/structure completely and pull that tag's value to navigate on double-click.
Nice! That's a great idea as well. I'll keep that in mind for future projects.
What is your workflow/strategy for highlighting the device related to the alarm? Do you have an invisible rectangle behind the device that you change is visibility property for a set period if time?
Basically I have a bright pink/fuschia rectangle behind or in front (depending on how much the graphic fills the rectangle) that looks at a client tag named (I think LocatorTagPath) If the object's tag path matches, I flash the rectangle for like 5 seconds, then set LocatorTagPath to a blank string, which inherently stops the blinking. I also have a search function that searches the tag database for a user entered string (I prefix/suffix wildcard * so that it will partially match), then let the user select from a dropdown the tag they want to find, and click "Go to Screen" and it does the same thing as my alarm double-click.
Here is my first attempt at it, it works but I feel like there is a simpler solution. How is this the flow?
Double-click runs a script that writes the tag path to the LocatorTagPath and then swaps windows
Rectangle Component has an animation style that flashes when the rectangle is visible and it has two custom properties (deviceName and alarmDeviceName)
alarmDeviceName is bound to the LocatorTagPath
deviceName is the name of the related device
I created a component script on propertyChange that checks if deviceName is in the AlarmDeviceName and will make the rectangle visible for 5 seconds then clear the LocatorTagPath.
I've gone the one big project route for a WWTF project that I've been working on for the last year. I've got 5 different providers, one for each "control area". Each control area has a panel PC that runs a big project client and has an Edge Gateway with a fallback project of the same big project, but there are tags that detect witch control area the gateway is in (by IP address) and limit navigation based on the control area.
It's been great! Maintenance is easy because all projects share tags, UDTs, and templates, rather than having to update UDTs and templates for multiple, smaller projects.
That's pretty much what I have. If your alarmDeviceName is bidirectionally bound, you can also just set it to a blank string rather than doing a writeAsync, otherwise, that's the main difference I had.
So on each control area with the Panel PC, is the panel PC the realtime tag provider locally and the remote tag provider of the same name in the "master" project?
Tag providers are duplicated. Once in the master project, once in the fallback project.
This is the only way that made sense to me, considering that the edge gateway PCs are running as clients of the central gateway with local fallback projects to control only the local area. If the edge gateway served tags to the central gateway, losing an edge gateway would mean losing visibility to the area, even if the PLC and everything in the area is still OK. Conversely, if the edge gateway pulled tags from the central gateway and the central gateway went down, you wouldn't be able to control the local area at all either.
If local clients lost comms to the central, they'd fall back to the panel PC and still be OK, but I didn't think of the scenario of the panel PC losing comms to the local PLC then going blind in that area (which is more likely to happen than the central gateway going down). Your config definitely covers all bases though, so if I ever get a project structured like that, I'll definitely take your suggestion on setting them up separately. (I guess my concern was that if comms loading from 2 servers communicating to single PLCs would be too much, possibly, depending on how many tags you're polling)