Hello,
I turn to your experience for a little opinion. I have several small / medium projects (interfaces in perspective insert / select SQL + data presentation), as well as some HMIs and some API calls, for several departments. How do you suggest they be organized?
-
A big project with all the departments
-
Each departments with own project (sometimes data will travel between departments)
-
Two big projects: First one with all HMIs and everything related to direct production, Second one with all support apps (fancy reports for daily - weekly - monthly KPIs, prod. planning, quarter inventory, 'project that if something happen they will not stop production)
Have same Tag Provider & Identity Provider for every project
Thanks
The maintenance and work involved in having multiple projects for me always leads me to using as few projects as possible. Usually that’s a global project and a main project which inherits from the global, and maybe an alarm pipelines project, but really that’s only because that’s how 7.9 projects are converted to 8. I will only have separate projects if:
- The project is completely independent, e.g. an edge hmi for an oem machine
- The customer doesn’t want project saves to affect multiple areas of the site. Usually these would be significant areas or sides of the business which are essentially independent of one another
I think that’s about all. It becomes a nightmare trying to manage multiple sets of udt types. It would be nice for udt types to be able to be inherited from from a tag provider sense
Right ? I have the same UDTs in 5 different tag providers for 5 similar projects, each time a change is made somewhere it has to be propagated to the other ones, unless you want to have out of sync UDTs, which will without fail end up in a maintenance nightmare.
I which we could have a 'template provider' or something of the sort, where you could set up UDTs, and maybe folder structures, that you want to reuse in different projects.
1 Like