I am just curious as to how you are naming your projects, db connections, tag providers, etc...
I follow the structure below but I was wondering what everyone else does?
What are your best practice naming conventions? Thanks!
I found that project name with underscores and the title with exactly the same name but with spaces avoided a lot of confusion.
how about real time tag providers and other connections?
Those aren't project resources. Don't make such based on a project name unless the remote system only has the one project. (In which case it probably should be the remote system name, not a project name.)
depending on tag count, I typically create a Real time tag provider for each project or set of like equipment. Are you saying that's not good practice?
In my opinion, it is not a good practice, as you cannot share UDT definitions across tag providers. I generally recommend only a single local realtime tag provider for all plant devices local to that gateway. In addition to ensuring maximum UDT sharing, it also simplifies remote tag provider setup on any central gateways.
Is there a tag limit or is it gateway limit for your tag providers?
Maybe its because how I was trained in 7.7 from many years ago and I just kept it going with a tag provider per project. There was a 1k tag limit per scan class and I forget the overall tag limit before resources were an issue.
Do you just add a folder structure per equipment? I'm glad I asked this question as its the opposite of what I have been doing.
I don't recall ever encountering that. Sounds like the OPC issue that sometimes would need extra tag groups (not tag providers).
Yes. Usually further nested in folders for areas of the plant and/or specific production lines.
It was per scan class, we ran into it with 50k+ tags on the same scan class. We had to stagger the scan classes, every 1K was changed by 100ms so they would get their own thread per inductive support. The issues went away after that.
**NOT an issue with version 8, this was version 7.7.
Scan class ~~ tag group. And no, you should not have needed different group rates. (You certainly do not now.)
Just a follow up to the original post, do you just put everything into the default tag provider?
Mostly, yes. But most clients rename the default provider to reflect their site name. That makes it practical to use the same name in RTPs pointing to that gateway.
Thanks for the info, whats your naming standard for those? Site/function? Site/area, Site/gateway?
Abbreviated site. If a site is big enough to have multiple gateways (other than redundancy), presumably there would be some suffix.
(I do not recommend putting multiple gateways on the same site, normally. Definitely not Edge on the same physical site as Standard.)
? What about critical machines that need a fail over to a local edge client?
They should fail over within an on-site redundant pair. If the network is the concern, spend a little on redundant network drops (rapid spanning tree or comparable).
Edge local client failover is only appropriate when the main gateway is physically remote. IMNSHO.
So something like?
site_function_gatewayIdentifier
mysite_widgets_gateway1 or something similar?
??
No, more like [ATL] for a tag provider in the one gateway (or pair) in a company's one facility in Atlanta. Site abbreviation within the company. Folder names within the tag provider would offer the remaining structure.
The big companies I know assign short abbreviations to all the sites they have. Leverage that.
that's correct, we do similar here. I was thinking of the segregation between multiple gateways at one site, we tend to use the scale out architecture with front ends and multiple back-end gateways (gateway per division). I'm probably overthinking it but just walking through all of the options.
I appreciate the info as always.
Simple. Don't do that. At least not for backends. (Perspective front-end scaleout is a different situation, but those should not have anything in a local tag provider, just RTPs.)