An Ignition Edge Panel is a full Ignition gateway with a local HMI, sized for one skid or one remote station. If a single plant already has, or will soon have, a central gateway, install client software on the floor panels and point those clients at the central gateway. Add Edge only where a station must keep running after it loses the plant network, or where it is too far away for a dependable LAN link. Run the central gateway on a server with spare CPU cores and RAM, keep the database on a separate machine, and handle network breakage with RSTP rings. A second gateway is the wrong tool for that job.
Symptom Readout: Quantities Past Their Limits
Architecture mistakes with Edge show up as measurable limits being hit: a session count, CPU and heap load, PLC connection count, link bandwidth, or engineering hours spent on duplicate configuration. Use the table to map each symptom to its cause before you change hardware.
| Symptom | Quantity past its limit | Root cause | Where to read it |
|---|---|---|---|
| An additional viewer cannot open the Edge project | Perspective sessions on Edge: 2 total, and the local panel holds one | Viewers point at Edge instead of the central gateway | Perspective session status on the Edge gateway web interface |
| Central gateway slows down or restarts during trend or history queries | CPU saturation or memory exhaustion | Gateway runs on an undersized iPC or VM, often sharing the host with the database | Gateway status/performance page (CPU, memory, threads); OS resource monitor |
| Every tag change has to be made twice, and screens disagree | Two tag configurations for one process | Edge deployed in the same plant as the central gateway it feeds | Tag browser on both gateways |
| PLC communication load rises after Edge is added | Connections per PLC doubled | The same device is polled by both Edge and central | PLC connection diagnostics; device status on each gateway |
| Trend gaps or stale tags from a remote site on cellular | Link bandwidth | Gateway network traffic running over a thin link | Modem or router link utilization |
| A SQL report against Edge history fails | No external database connectivity | The Edge historian is an embedded SQLite store | Built-in historian query functions only |
Edge Is a Gateway: Role and Data Path
The "edge of the network" in Ignition Edge means geographically scattered. It does not mean the far end of a plant LAN. Edge is an Ignition gateway that can also drive an HMI. Deploying it creates a second tag system with its own device connections, project, historian, and security configuration. With a central gateway in place, data follows this path: PLC to Edge device driver, Edge tag provider, gateway network, remote tag provider on central, then clients. Each hop must be configured, secured, backed up, and version-controlled.
On a flat, on-site network, adding a second non-redundant gateway gives almost nothing back. A client on a touchscreen PC at the machine, connected directly to the central gateway (preferably a redundant pair), reaches the same PLC data with one hop and one project. Putting Edge in the same plant as the central gateway it feeds adds code, project management, and data-flow management that the end user pays for and gains nothing from. The extra cost is engineering hours. The control problem is the same either way.
Edge fits these cases:
- Standalone skids that run independently of other systems, as a PanelView-class HMI replacement at lower cost.
- Remote sites or stations physically distant from the main network that must keep running when the central gateway is unreachable.
- Small local systems that need local history but no external database. Edge stores history in a built-in SQLite database that you query only through the built-in historian methods.
Perspective Session Budget on the Edge Panel
The number that matters is two. Edge provides 2 sessions for viewing the project running on Edge. A gateway-network connection from the central gateway does not use one of them. A local Perspective panel does use one, which leaves one session for a laptop or a second screen. That is enough for design and troubleshooting and too few for operations. Once the system is in use, clients belong on the central gateway, so plan for unlimited client licenses there.
Treat the Edge project URL as a designer tool. Use it for troubleshooting and testing among engineers. If a second on-premises client is unavoidable, run it as a Perspective Workstation that connects to the full gateway by default and falls back to Edge only when central is unreachable.
Apply this to a layout with three hallways (A, B, C), one display each. You can place an Edge Panel per hallway, which gives three gateways, three projects, three historians, and three sets of device connections. Or you can place one client per hallway on the central gateway, each opening a view filtered to that hallway's tags. Unless each hallway has to run when the plant network is down, the second option gives the same screens with a third of the configuration surface.
Central Gateway Compute and Database Placement
Ignition runs best with excess CPU cores and plenty of RAM. A conventional iPC is a poor host for a central gateway. The limit is thermal and computational headroom under peak load: historian queries, concurrent sessions, alarm evaluation, and script execution all land at once. One undersized cloud VM bogged down and restarted whenever users pulled historical data. That is heap and CPU exhaustion, not a logic fault, and it is the typical failure of an under-provisioned gateway.
Vision and Perspective load the gateway differently. With normal licensing a central gateway can serve hundreds of Vision clients, because rendering and much of the client logic run in each client's own runtime. Perspective keeps per-session state on the gateway, so each session consumes gateway memory and CPU, and a given server supports fewer Perspective clients than Vision clients.
| Deployment | Server count | Layout |
|---|---|---|
| Production, non-redundant | 2 | One gateway server, one database server |
| Production, redundant | 4 | Gateway pair plus database pair on separate machines |
| Production, redundant, virtualized | 2 physical hypervisors | One gateway VM and one database VM on each host |
| Evaluation bench | 1 iPC | Gateway and database co-hosted; results are not representative of production |
For an evaluation bench covering a small slice of an existing project, a capable iPC such as the OnLogic Helix 401 can host a gateway and a test database. Read the core count and maximum RAM from the unit's datasheet. Then watch CPU and memory on the gateway status page while running history queries and holding the expected session count. A result on a co-hosted iPC tells you the software works. It does not size the production server.
Data Transport: Gateway Network Versus MQTT
When Edge feeds a central gateway, the PLC data is polled by the Edge gateway's device drivers. The central gateway sees it through a remote tag provider over the gateway network (GAN). For very distant sites, such as those on cellular modems, publish from Edge to central over MQTT, which uses less bandwidth than the gateway network.
| Transport | Best fit | Bandwidth demand | Mechanism |
|---|---|---|---|
| Gateway network with remote tag provider | Edge sites on plant WAN or reliable links | Higher | Central browses and subscribes to Edge tags as if local |
| MQTT | Cellular, satellite, or metered links | Lower | Edge publishes on change; central subscribes through a broker |
Set the connection direction so that every Edge gateway opens an outgoing connection to the central gateway, and the central gateway accepts incoming connections only. The firewall at each site then needs no inbound rule, Edge devices behind NAT or carrier-grade cellular addressing still connect, and the central server's exposure is limited to one listening service.
For a fleet of several Edge gateways on one central server, bring field data into central only through the GAN. Add no devices and no polling engines to the central gateway. Keep that polling on the distributed Edge devices. The central server's CPU then goes to sessions, history, and alarms instead of driver threads, and each PLC has exactly one poller.
Network Break Tolerance: RSTP Rings Versus Gateway Fallback
Inside one plant, a network break is a switching problem. Move the plant backbone to a redundant topology running RSTP or a similar ring or mesh protocol on the managed switches, so a cut cable reconverges to an alternate path. A fallback gateway does not cure a single-path network. It moves the outage onto a second project you have to maintain.
Match the redundancy mechanism to the failure you are protecting against:
| Failure to survive | Mechanism |
|---|---|
| Cable or switch failure inside the plant | RSTP (or similar) redundant network |
| Central gateway server failure | Central redundant gateway pair |
| Edge hardware failure at a remote site | Edge redundancy (licensed through the Inductive Automation sales channel) |
| Skid on the plant network that must operate during a network break | HMI runs from central by default, failing over to a local Edge client on network loss |
Architecture Selection Procedure
- List every HMI location with its physical position and the network path to the central server room.
- For each location, decide whether it must run the process with the central gateway unreachable. That determines autonomy.
- If the location is in the same plant and does not need autonomy, install a client on a panel PC and connect it to the central gateway. No Edge license and no EAM are needed.
- If it is an autonomous skid, deploy Edge as a standalone HMI with local PLC connections and use Vision for the operator screens.
- If it is a geographically remote site, deploy Edge. Connect it to central with an outgoing GAN connection and a remote tag provider, or with MQTT on a thin link.
- Once any Edge gateway reports to central, install the EAM controller on the full gateway. Manage all projects there and push them to Edge periodically. EAM only matters when more than one gateway exists. A single central gateway with plain clients does not need it.
- Size the central gateway as a server with spare cores and RAM, and put the database on its own server.
- Choose redundancy per the table above: RSTP for the network, a redundant pair for the central gateway, Edge redundancy only for critical remote hardware.
Building the Edge Panel Evaluation Bench
If the task requires evaluating an Edge Panel for future projects, set it up in the role it will actually fill: a standalone skid that can later report to central.
- Install Edge on the panel hardware and configure a device connection to one PLC from the existing project.
- Build the local screens in Vision if the panel will serve as a machine HMI. Budget real time for touch-panel setup, including kiosk launch, on-screen keyboard behavior, and touch target sizing. Configuring a touch panel as an HMI on an Edge gateway takes considerably more effort than it first appears.
- Enable Edge history and confirm that trends render from the embedded SQLite historian.
- Configure an outgoing gateway network connection from Edge to the bench central gateway, and approve it on central.
- On central, add a remote tag provider pointing at the Edge gateway's tag provider, and bind a test view to those tags.
- Install the EAM controller on central, register Edge as an agent, and push a project revision to Edge.
- Document the limits you observe (session count, history access method, configuration hours) as input to the production architecture decision.
Verification Checks
- Session budget: open the local panel plus one laptop session on the Edge project, and confirm the central gateway connection does not reduce that count.
- Autonomy: pull the Edge uplink. The local HMI must keep operating and historizing. On reconnect, the remote tag provider on central must return to good quality without manual intervention.
- Single poller: in the PLC connection diagnostics, confirm each controller has one connection from Ignition. A second connection means central is polling a device that Edge already owns.
- Connection direction: confirm the site firewall has no inbound rule for Edge and that central shows the connection as incoming.
- Gateway headroom: run the heaviest history query while holding the target session count, then read CPU and memory on the gateway status page. Sustained saturation or a restart means the host is undersized.
- Ring recovery: break one RSTP ring link and measure how long clients stay disconnected. Compare the result against the process tolerance you have defined for that area.
- EAM push: change a view on central, push it, and confirm the Edge project revision matches.
Recurring Pitfalls on Edge Deployments
- Perspective as an on-machine HMI. For PanelView replacements and plant-control HMIs, use Vision. Perspective suits SCADA that mainly monitors many plants rather than controlling them. A defensible exception is a standalone skid where the customer wants phone access over a Wi-Fi router in the panel.
- Edge fallback instead of a redundant pair. Server failover belongs to a central redundant pair. Edge fallback in the same plant doubles project maintenance without covering the gateway-server failure it is meant to cover.
- Distributing the Edge project URL. Every operator bookmark consumes one of the 2 sessions and bypasses central security and auditing. Keep that link among designers.
- Polling devices on central in an Edge fleet. This duplicates PLC load and pulls driver work back onto the server you are trying to keep free for sessions and history.
- Treating Edge history as a database. The SQLite historian is reachable only through built-in historian methods. Reporting that needs SQL belongs on the central gateway and its database server.
- Co-hosting gateway and database in production. This works on a bench. In production the two compete for the same cores, RAM, and disk I/O during exactly the history-heavy periods when operators need responsive screens.
FAQ
How do I connect an Ignition Edge Panel to a central Ignition gateway?
Configure an outgoing gateway network connection from Edge to central, approve it on central, and add a remote tag provider on central that points at the Edge tag provider. For cellular or other bandwidth-limited links, publish from Edge over MQTT instead, since it uses less bandwidth than the gateway network.
How do I put SCADA screens on plant-floor panels without buying Ignition Edge?
Install the client software, preferably Vision for machine HMIs, on a touchscreen panel PC and point it at the central gateway. With normal licensing one central gateway serves hundreds of Vision clients, and every panel shares one project, one tag system, and one database.
When should I stop troubleshooting and contact Inductive Automation?
Escalate through official Inductive Automation support if the Edge session count or license entitlements differ from what your license shows, or if EAM pushes or gateway network connections keep failing after you have verified the outgoing connection and firewall path. For Edge redundancy licensing and unlimited client licensing on the central gateway, go through your Inductive Automation sales representative.