Ignition edge single project restriction

Ignition edge version allows a single project.

IMHO it is very annoying for deploying edge on several sites where the project's inheritance feature would be very usefull to deploy and update some common scripts and views we could gather in a project inherited on each sites.

EAM has to many restrictions to select scripts and views to sync.

1 Like

+1

Meh. Have you noticed how much cheaper Edge is?

Allowing only the one project eliminates a whole bunch of potential problems that IA support won't have to deal with, helping keep that astonishingly low price.

I agree Ignition Edge has an excellent price/features ratio.
The only feature missing for large scale rollouts is an efficient way to distribute update.

The perfect way for me would be to distribute a common project inherited by each edge site project. EAM can do that, but with the edge single project that's not possible.

Syncing some parts of project is a pain, because EAM does'nt support some "folder" sync feature wich could sove this issue. (Each time you add some ressources in the master profect you need to change EAM settings, and check each ressources to synchronize...)

It would be a pity to add an external tools on each edge device to sync the file

If projects are configured correctly, then EAM CAN distribute those resources, just make sure that you select to include inherited resources before sending the project (small checkbox within EAM task config).

@ Full Gateway (2 projects)

  • Project1 <-- GlobalProject (Inherited)

@ Edge Gateway (1 project)

  • Project1 (with GlobalProject resources Included/merged)

The resources do not appear as Inherited when viewing those within Edge Designer session. Though, one would argue that with EAM, you should never have a need to open a project in Designer directly on an Edge gateway.

3 Likes

Thanks, in my use case, it means the following projects:

@Central GW
All Sites GUI <- Site A Data <- Site B Data <- Site C Data <- Common
Site A GUI <- Site A Data <- Common
Site B GUI <- Site B Data <- Common
Site C GUI <- Site C Data <- Common

@Edge GW Site A
Site A GUI

@Edge GW Site B
Site B GUI

@Edge GW Site C
Site C GUI

(With respect of the Ignition limitation: Inheritable projects are not runnable as a stand-alone project)

with EAM sync Central GW => Site A, B, C

If I'm reading your message correctly, it looks like:

  • "Site A GUI" is runnable, and inherits "Site A Data" project.
  • "Site A Data" project is inheritable (not runnable), and also inherits "Common" project.

If you want "Site A GUI" project to exist on "Edge GW Site A", except contain the resources of both inherited projects ("Site A Data" and "Common"), then your EAM Task may be configured to "Include inherited project resources" while selecting the project "Site A GUI" from the source gateway. This should collect ALL inherited resources for that project and combine them to a single project before sending the project to the Edge gateway.
A note just above that checkbox indicates:

If checked, the selected project and any inherited resources will be combined into a single project on the target agents.

Then, you add 2 additional tasks to cover all three Edge gateways. Depending on your schedule, all 3 gateways would contain 'up-to-date' versions of the "Common" resources, and each would also pick up their site-specific ("Site X Data") resources.

Yes that's the idea. Thanks for the mention about the EAM checkbox to combine inherited resources in a single project ! I was more used to sync projects without this option with Ignition standard Edition

1 Like

How is this possible? "Site A Data" can only inherit from Common or from "Site B Data". Which is it?

Oops I forgot I was on the same gateway !
So I dont see any good parh to manage a central gateway and edge sites....
With all sites available in the central gui, and some common scripts and ressources inherited everywhere.

If someone has any idea...

Probably just keep everything inheriting from Common.
I'm not sure what you're currently planning to inherit from Site N Data to All Sites GUI (Views? Named Queries?), but most likely it's something that you can put in Common and use parametrization to be able to use the Site A, B, or C version.

Something like the below:

EDIT: The multiple inheritance issue has come up multiple times before, with a couple of different workarounds depending on the situation, so here's another workaround:

So you could also try some chain of Common -> A -> B (now AB) -> C (now ABC) -> All Sites and have some unnecessary resources floating around in your B and C that only exist to be inherited by your All Sites.

On the central Gateway

All Sites GUI <- Site A <- Site B <- Site C <- Common

EAM sync the project Site A to Edge A (with combined ressources option checked)
EAM sync the project Site B to Edge B (with combined ressources option checked)
EAM sync the project Site C to Edge C (with combined ressources option checked)

I need to test if it can be done because Site A project on the central Gateway is not runnable, and it need to be runnable on the edge Gateway.

In order for the project to be runnable on the Edge gateway, it must be runnable on the full gateway. It might be ugly, but could you create a new project (which IS runnable) that inherits Site A (and all parent projects), then send that project via EAM?
Otherwise, rearchitecting projects, or a bunch of complicated EAM tasks might be in order.

1 Like

To illustrate what Chris_Bingham is saying:

Central Gateway has the following projects:

All Sites GUI <- Site A Core <- Site B Core <- Site C Core <- Common
Site A (Runnable) <- Site A Core <- Site B Core <- Site C Core <- Common
Site B (Runnable) <- Site B Core <- Site C Core <- Common
Site C (Runnable) <- Site C Core <- Common

But it's definitely not pretty.

Edit: this actually looks really similar to what you posted earlier, just with the corrected inheritance hierarchy (and inherent bloat incurred in Site A and Site B).

:scream: it's a bit ugly, especially if I need to scale and add more edge sites.

1 Like

Your best bet is probably to rebuild from the ground up and make the site projects as modular and reusable as possible, so you only have 1 actual parent project for the whole collection.