Limit on project inheritance?

Is there like a limit for how many projects that can be inherited? I mean in the sense that this is slowing down the system, launch times, client behaviour. Or something like this?

The reason I ask is that we have multiple libraries. Each library is defined in its own inheritable project.
If our customer has 4 different PLC libraries within different brands (siemens/rockwell/ABB etc).

global ->rockwell_lib1->rockwell_lib2->siemens_lib1->abb_lib1->myMultiLibProject

You are trying to shoe-horn multiple-inheritance behaviors into a single-inheritance model. Until IA implements the former, you should place all truly globally common libraries in the root inheritable project. other inheritable projects can collect shared resources for subsets of leaf projects, but the “library” concept simply is not feasible.

this While technically possible, it will be a mess to maintain, also debugging all those projects in a chain could prove to be a nightmare in some scenarios.

If you only care about scripts and truly want “library” functionality, then you can manage the pylibs external to Ignition and just load them to the user-lib folder on the gateway.

1 Like

Thanks for the feedback guys.

I forgot to mention that the libraries are only for popups, and “global objects”(object indication).

I was thinking that if the structure of the libraries were good. Then this would be feasible.

  • all templates and popups were segmented in specific folders libraries/lib01/
  • all libraries would be fully segmented(standalone)

I would expect these library projects only to have one folder in windows (popups), and one folder in templates and one folder for scripts. I Dont really see the maintenance problematics @ryanjmclaughlin mentioned.

Its just that we are delivering projects to multiple customers, and some customers do not need all libraries.

Also, if we update the library for one customer, we could simply import it directly to the other customer lib-project.

@pturmel, I dont really like it either. But for me it looks like the best solution, but would it not be feasible?

Inheriting from more projects shouldn’t cause any noticeable issues with the system. On startup the gateway will have to scan through all the projects you have, but if each project has fewer resources I wouldn’t expect any noticeable increase in start time. The client sees what we call the “effective project” – a flattened down view of the inheritance, so you shouldn’t see a difference there. There is a small hit on flattening the project, but again total number of resources would be more important than number of projects.

But like others have said, I don’t think the chain you described will do what you want. When you want the same chain but without rockwell_lib1 for another customer, you’ll be having to make rockwell_lib2a, sienmens_lib2 and abb_lib2 and maintain all of those. If you’re happy with that, try it and see how it works for you.

Aah I get it now.

In my mind one project would have only lib_b while the other project within the same gateway would have lib_a and lib_b. That combo is not possible.(as lib_b is stuck with lib_a)

I rest my case. Thanks all for the feedback!

1 Like