Skip to main content
Version: 8.1

7.9 to 8.1 Upgrade Guide

Ignition 8.1 is a major update across virtually all subsystems and modules. Inductive Automation strives to maintain its commitment to backwards compatibility and a straight-forward upgrade process. However, given the vast scope of changes in 8.1, there are inevitably special considerations that need to be evaluated and actions taken in order to successfully upgrade an existing system. This document seeks to identify those issues and provide guidance for users who are migrating from an Ignition 7 system. To discover the new features of Ignition 8.1, please see the What’s New section.

note

In some cases, it is not advisable or possible to upgrade from Ignition 7 to 8.1 at this time. Please read this guide carefully before upgrading a production Gateway.

Upgrade Process​

When upgrading from Ignition 7 to Ignition 8.1, there are two general approaches.

Using the Installer to Upgrade (Preferred Approach)​

Using the Installer to upgrade is the easiest approach. Simply run an Ignition 8 installer on your existing server (similar to how upgrades normally work). As always, we highly advise taking a Gateway backup before upgrading.

Importing Projects into a Fresh Install​

We have found that some users prefer to completely uninstall their Ignition 7 Gateways, install a fresh copy of Ignition 8.1, and then manually import projects and Tags from the old Ignition 7 Gateway, one-by-one. We generally discourage this practice, as it results in unintended consequences. We recommend you take the "Using the Installer to Upgrade" approach instead. However, if you must import Ignition 7 resources into an Ignition 8.1 Gateway, then we recommend you use Gateway Backups instead (when possible).

The reason for this, is that a Gateway Backup triggers an upgrade check that looks over the Gateway Backup and makes modifications to the resources so they run as expected on an Ignition 8.1 system. The same check is triggered when running the installer. Project and Tag imports do not trigger this check. As a result, you may need to make manual modifications to the imported resources.

For example, the project system in Ignition 8.1 is drastically different, so running the installer directly on an Ignition 7 Gateway or importing an Ignition 7 Gateway Backup into an Ignition 8.1 Gateway will trigger all of the updates listed under the Project Inheritance & “Global” Upgrade Logic heading below. Individually importing projects one-by-one will not trigger the upgrade logic, so any legacy "shared" scripts may not work in Ignition 8 without user intervention.

The same could be said for Tag imports. Ignition's built-in OPC UA server connection on Ignition 7 used the name "Ignition OPC-UA Server", but Ignition 8.1 changed the name to "Ignition OPC UA Server", removing the hyphen "-" character. As a result, your Ignition 7 Tags are likely using the old name, where as a freshly installed Gateway is using the new name. Thus, OPC Tags imported from an Ignition 7 file will likely break upon import as the OPC Server name won't match, so you'll need to either A) rename the OPC UA server connection or B) find-and-replace the OPC UA server name on all of the Tags.

Changes That Require User Action​

These changes will require manual action on the part of the system administrator/project author. In other words, these are features or situations that have a direct corresponding solution, but for various reasons cannot be automatically upgraded.

Look and Feel changes​

The general look and feel of the Ignition Designer and Vision Client has been updated. This may result in subtle changes to the appearance of Vision Clients depending on the components used by a given project. It is not possible to revert to the old “look and feel” as it’s not compatible with new version of Java.

This means screens that have been developed in version 7 may look different after upgrade. Notably, the default font on many Vision components is larger. To preserve your pre-8.0 look, you will want to enable the Use Condensed Font Gateway setting (introduced with version 8.1.4).

Manual configurations to Vision resources, such as manually selecting a font or background color for a component, will be preserved upon upgrade. However, visual properties left with default values may appear differently after upgrade.

note

It is highly advised to upgrade version 7 projects to version 8.1 on a test server and verify the look of the project, before upgrading the production servers.

Redundancy Connection Configuration​

Redundancy communication is now accomplished through a Gateway Network connection between the master Gateway and the backup. This mechanism provides greater security and performance than the previous communication channel, but will require the system administrator to re-establish the connection.

The settings for the communication channel are still configured in the Gateway under Configure>Redundancy, and are still established from the Backup to the Master, but must be modified before the backup will successfully connect to the master after upgrade.

Replacement for the system.tag.browseConfiguration Function​

The Tags system in Ignition changed dramatically in Ignition 8, which makes the Ignition 7 function system.tag.browseConfiguration obsolete. The function has been removed from the code base, so scripts using the old browseConfiguration function will break upon upgrade. The functionality has been replaced by system.tag.getConfiguration.

OPC UA Certificate Management​

Prior to Ignition 8, Ignition’s built-in OPC UA client implicitly trusted the certificate of any server it connected to, and Ignition’s built-in OPC UA server implicitly trusted the certificate of any client connecting to it. This is no longer true. New certificate management pages for the client and server have been added to the configuration section of the Gateway under “OPC UA > Security”. From this UI, trusted certificates can be imported and quarantined certificates can be marked as trusted. Ensuring the remote certificate is trusted, is required for all secured inbound and outbound connections.

On upgrade, all secured inbound and outbound connections other than the default “loopback” connection will be faulted until the remote certificate is explicitly marked as trusted.

Query Tags​

New in 8.1.3

Query Tags in Ignition 7.9 have a default behavior that allow Array and Dataset type Tags to ignore AutoDetect logic and execute queries as SELECT statements. Starting in 8.1.3, if a Query Tag does not start with SELECT, Ignition will execute the query as an UPDATE query. Manually selecting either SELECT or UPDATE will circumvent any issues that may arise from this change.

Quality Codes​

8.1 quality codes are different from the quality codes in 7.9. Existing values are adapted automatically so tag history quality results and bindings can still be trusted in your upgraded versions. However, it is important to check areas where manual entry may prevent adapted values from populating correctly such as scripts for live checks of tag quality.

Discontinued Features​

These are areas that have been removed or discontinued, as new methodologies have been adopted to replace the functionality.

Vision Mobile Module Discontinued​

The Vision Mobile Module is no longer supported in Ignition 8. The new Ignition Perspective Module provides a robust, modern solution for mobile visualization. Users should migrate their mobile visualization needs to be based on Perspective applications going forward.

A few important points:

  • The Mobile Module will continue to be supported on Ignition 7.9 for the remainder of its respective Long Term Support (LTS) terms.
  • All customers who own the Mobile Module and have current TotalCare Upgrade Protection contracts are entitled to a license of Perspective Mobile upon upgrade.

External Database “SQLTags” Providers No Longer Supported​

The “Database Provider” and “Database Driving Providers” are no longer supported in Ignition 8. These systems were very early ways to bridge outside data into Ignition’s Tag system and have been replaced over the years with much easier and faster methods of data integration.

32 bit Support​

Support for 32-bit platforms other than ARM has been discontinued.

Project Rollback​

The Project Rollback feature has been discontinued in Ignition 8.

OPC UA Server Stale Threshold​

The Stale Threshold setting on Ignition's OPC UA server has been retired. The setting was originally used in earlier versions of Ignition as a means to help some of our drivers determine when values should be marked as stale. Our drivers have since gained their own methods to determine staleness. The setting has little use in Ignition 8, so it was removed.

Staging and Publishing​

Ignition 8 features a completely revamped project system. This new project system does not have different “staging” and “published” versions of each project. When you upgrade from Ignition 7, any projects that were split into separate staging and publish versions will have their staging versions imported into Ignition 8. This is to prevent any loss: the staging version is always at least as and usually more up-to-date than the published project.

Staging and publishing was not included in Ignition 8’s project subsystem for two reasons:

  1. Staging and Publishing was not consistently implemented across various modules, leading to confusion about which types of resources participated in it.
  2. Projects are not self-contained; they rely on tags and external connections to devices, databases, etc. For this reason, the staging and publishing feature was only effective in limited circumstances.

You can emulate the old staging and publishing system by simply having a “staging” copy of your project and either move resources between projects or copy & overwrite them in order to “publish” your changes.

OEM Lock​

The “OEM Lock” feature that was used to encrypt project resources by authors is not currently supported in Ignition 8. Project authors that used this feature may migrate their projects to 8.0, as the owner license will decrypt Ignition 7 resources, but they should be aware that the resources will currently remain unencrypted.

End users who upgrade OEM-Locked systems to 8.0+ will not be able to view the project resources.

OPC UA Server Exposed Tags Auditing​

When a Tag made available via the “Exposed Tags” feature of Ignition’s OPC UA server is written to by an OPC UA client, the write is not currently entered into the audit log.

OPC UA Server “ReadOnly” Role​

The undocumented “ReadOnly” role no longer has any effect.

Changes to Be Aware Of​

Ignition 8 has many additional changes and improvements that system administrators should be aware of. Although none of them present a significant issue, some may directly affect end users (for example, launching clients), and some can be leveraged to improve the security and performance of your system.

Third-Party Modules​

Please consult individual module authors concerning upgraded module availability. Modules built for Ignition 7 will not work in Ignition 8 without modification.

Tag Historian Licensing​

See the Tag History Licensing changes on the [Upgrading from 8.0 to 8.1] page.

Default Security Certificate​

Ignition installations no long come with initial security certificates.

Native Client Launchers Replaced​

The Native Client Launcher has been replaced by the Designer Launcher and Vision Client Launcher, which offer similar functionality. Due to the aforementioned "Default Security Certificate" change, secure connections between the launchers and Gateway will require valid certificates are in place.

Java Web Start Discontinued​

Support for Java Web Start has been discontinued by Oracle and the OpenJDK community as of Java 11. This technology has been used in Ignition since its original release to launch the Designer and Vision clients, though we have also offered alternative launching tools for years.

In anticipation of this change, the designer and client launching tools have been greatly improved in Ignition 8. In addition to a fresh and more functional UI, the launch tools now manage the Java runtime environment used by the client (see next point), and can help you track many projects and Gateways. There are separate launchers for Vision Clients and the Designer, representing the natural distinction between the target users of these products, and the launchers can be downloaded for Windows, Mac, and Linux directly from the Gateway homepage.

Java Web Start is no longer supported, please use the Designer and Client launchers to launch those applications.

Embedded Java​

Ignition no longer requires Java to be installed on the Gateway or client machines. Native versions of the Ignition installer and launchers have been made available for 64-bit Windows, Mac, and Linux, as well as ARM, for use in edge devices. These distributions include embedded JREs (Java Runtime Environment) that are provided by Inductive Automation and managed by Ignition.

The native client launchers manage retrieving the current version of the JRE as necessary for the client and designer runtimes. Updates to the embedded JREs are managed by Inductive Automation and are made available through updates to Ignition. The client launchers will automatically update their local versions as necessary, ensuring that Vision Clients and the Designer are always running the latest version available on the Gateway.

Ignition no longer requires Java to be installed on server or client machines. System administrators should monitor Inductive Automation for important system and security updates, and can sign up for important notifications at http://support.inductiveautomation.com

Project Inheritance & “Global” Upgrade Logic​

The project system in Ignition 8 has been improved and now features a more flexible inheritance model. Each project may have a “parent” project, and will inherit all of the resources of that parent project. That project may in turn have its own parent project, and so in this way complex hierarchies of re-usable resources may be designed. Within each project, inherited resources may be used by other, “local” resources. For example, an inherited Vision template could be embedded in a window, or an inherited script could be executed by a button. Inherited resources may also be overridden, allowing them to be re-defined when needed. Conversely, resources in parent projects may be marked as “not overridable” to ensure that children cannot alter them, when appropriate.

This new inheritance system makes Ignition 7’s “global” project concept obsolete. In order to maintain backwards compatibility, the following will happen when an Ignition 7 Gateway is upgraded to Ignition 8:

  • The resources from the Ignition 7 special “[global]” project will be copied into an Ignition 8 standard, inheritable project called “global”.
  • All other projects will have their parent project set to this new “global” project.
  • All “shared” scripts are now simply project-level scripts in a top-level script package called “shared”, stored in the new “global” project. This allows all existing scripts to function without edits.
  • All “project” scripts are now simply project-level scripts in a top-level script package called “project”.
  • All Vision templates stored in the old global area are moved into a folder called “SharedTemplates/” in the new global project. The Vision module will automatically convert a template path like “[shared]MyTemplate” as “SharedTemplates/MyTemplate” so that no further action is needed.
  • If any run-always sequential function charts are present in the global area, a new project called “run-always-charts” will automatically be created upon upgrade, and these charts will be moved into this project. This is because resource types that execute automatically like run always SFCs and Transaction Groups do not run in inheritable projects.
  • If any alarm pipelines exist, a project called “alarm-pipelines” will be created and all alarm pipelines will be moved into this project. Tags can target pipelines in any project, but in the absence of a specific project, the pipeline is assumed to be in this special upgrade project.
  • There is a new Gateway-wide setting called “Gateway Scripting Project”. This setting lets you specify one project which all scripts that are outside the scope of a project will execute against. For example: Tag Change Scripts and Tag expressions using the runScript expression. On upgrade, this will be set to the new “global” project so that Tag scripts can continue to access shared.* scripting functions.
    • In addition to Tag scripts, this can potentially impact other features, such as expression items in a Transaction Group using the runScript function.

Deprecated system.tag Functions​

  • The system.tag.read and system.tag.readAll functions were deprecated. They has been replaced by system.tag.readBlocking.
  • The system.tag.write and system.tag.writeAll functions were deprecated. They have been replaced by system.tag.writeAsync.
  • The system.tag.writeSynchronous and system.tag.writeAllSynchronous functions were deprecated. They have been replaced by system.tag.writeBlocking.

Tag System Changes​

The Tag system has undergone significant changes in Ignition 8. The majority of these changes should go unnoticed upon upgrade (apart from obvious UI changes), and most systems should immediately benefit from improved performance, faster edits, and expanded functionality. To summarize:

  • "Scan Classes" have been renamed to "Tag Groups". Functionally they're identical. Scan Classes on Ignition 7 systems will gracefully migrate to Tag Groups upon upgrade.
  • "LastChanged" has been renamed to "Timestamp". Like Scan Classes, LastChanged values will migrate to Timestamp upon upgrade.
  • The Tag Editor has been gone through a major UI rework, but remains as easy-to-use as ever.
  • Tags are fundamentally defined via JSON structure now. A new right-click menu has been added to the Tag Browser, allowing you to edit the raw JSON of a given Tag. Additionally, Tag exports/import files now support a JSON format.

The upgrade process will attempt to convert older tags to the new system. Should this process fail, log files will be generated in the installation directory: /logs/legacy-tag-conversion (as of 8.1.11+). You can also leverage Tag Report Tool to identify broken tags.

UDT Performance​

The Tag system has been redesigned to optimize for UDT oriented design. In Ignition 7, certain aspects of UDT performance led some system designers to favor standard Tags over UDTs for some applications. Such systems should be re-evaluated in Ignition 8, as use of User Defined Types will lead to more efficient memory usage and lighter weight change processing.

UDT Parameter Usage​

The way that Parameter references are applied to Tags has changed. Instead of being replaced in a “pre-compilation” stage of Tag execution, they are now treated as true property references. This means that they can be modified, and those modifications propagate dynamically to referencing properties, causing those to be updated in turn.

An important consequence of these changes is that syntax for parameter references in Expressions has changed in a subtle, but crucial way. In Ignition 7, due to the replacement strategy, the following would have been a valid expression:

“The value of the parameter is: {ParamRef}”

In Ignition 8, this value would no longer be a valid reference. It is counter-intuitive to all other uses of reference in Ignition, and has been replaced with a more familiar syntax:

concat(“The value of the parameter is: “, {ParamRef})

All existing references will be upgraded automatically to the new syntax upon system upgrade. Designers should be aware of this change when creating new Tags.

UDT Parameter Formatting​

OPC tags using +00 in parameter bindings on their OPC Item Paths will return an Error_Configuration message as 8.0+ no longer allows +0# in parameter bindings when 7.9 allowed an arbitrary amount of zeroes. Changing this to +0 in the path will fix any broken tags.

note

Due to a change in 8.0.3 that "Improved mathematical operator support for UDT parameters", using operators such as + or - in your UDT Parameter is not recommended, as this can lead to Ignition executing a mathematical equation instead.

Quotes Taken Literally in String UDT Parameters​

In addition, string UDT parameters that contained quotation marks in 7.9 will now be represented literally. In 7.9 the quotation marks were omitted. After upgrading, the quotation marks will be included in the UDT parameter value.

The instanceName UDT Parameter​

The built-in instanceName UDT parameter works differently in nested UDTs. Referencing the parameter in a nested UDT will return the name of the nested UDT. In 7.9 the parameter would always return the name of the root UDT.

The UDTParentType Property​

The UDT property UDTParentType has been renamed in Ignition 8 to TypeId.

Script Based Tag Editing​

The various scripting functions for editing Tags (system.tag.editTag, system.tag.addTag, etc.) have been deprecated and replaced by system.tag.configure. The previous functions will continue to work, but designers should learn the new function, which is far more intuitive and powerful than the previous functions.

Tags are now defined as JSON objects, which consist of properties, arrays, and sub-objects. The system.tag.configure function can take either a String document definition, or a JSON object that defines one or more Tags. Overrides for UDTs are created by simple redefinition of properties, and complex structures like Event Scripts and Alarm configurations will be merged with inherited definitions.

OPC UA Default Configuration Changes​

New installations have some new OPC UA related defaults:

  • The server binds only to localhost (i.e. no remote connections allowed)
  • The server uses port 62541 instead of 4096
  • The server only allows secured connections (SecurityPolicy Basic256Sha256)
  • The default “loopback” connection is called “Ignition OPC UA Server” (there is no longer a “-” between “OPC” and “UA”)

Upgrades are not affected by these changes; they retain their existing configuration.

OPC UA Discovery with Third-Party Clients​

Ignition's OPC UA server disallows anonymous access on new installations, which can make the server endpoint difficult to discover by UA clients. To help with this, Ignition's UA server runs a separate unsecured endpoint to allow discovery. The discovery endpoint is accessible by appending /discovery to the end of the URL:

opc.tcp://1.2.3.4:62541/discovery

OPC UA Exposed Tags NodeIds​

When using the OPC UA Exposed Tags feature, the NodeId returned by the browse has changed slightly. In prior versions the NodeId would follow a pattern like: [prov]Path/To/Tag

As of 8.0+ the pattern now includes a slash after the provider: [prov]/Path/To/Tag.

Both patterns still function as expected for the purposes of Reads, Writes, and Subscriptions. However a NodeId returned by a browse will always use the newer pattern.

Changes to system.alarm.listPipelines​

The listPipelines function was changed to search a single project for pipelines. Upgrading from Ignition 7 to Ignition 8 will migrate all alarm pipelines into a project named "alarm-pipelines". To maintain backwards comparability, system.alarm.listPipelines() will check for a project named "alarm-pipelines", but now accepts a project name as a parameter, allowing the function to check for pipelines in any project.

SQLite Storage​

Gateways can now create SQLite databases, or "Internal databases" for many of the storage subsystems (Database Connections, Historian, Alarm Journal, and Auditing), allowing your gateway to store and retrieve data without needing to connect to a remote SQL database, which is useful for development systems and demonstrations.

note

We still recommend external SQL databases are used in production systems, as they generally offer a level of performance and redundancy not available to SQLite databases.

TLSv1.0 and TLSv1.1 No Longer Supported​

Ignition version 8.1.6 started embedding Java version 11.0.11 and Ignition version 8.1.33 started embedding Java version 17.0.8. These versions of Java do not offer support for TLS v1.0 and v1.1. This could impact connections the gateway makes to external systems and applications, especially so if those external systems cannot support a more recent version of TLS. The following items could be effected:

  • Database connections: This can generally be resolved by simply updating the JDBC driver that the gateway uses. Check your database vendor's JDBC driver recommendations.
  • HTTP calls from Ignition (such as those generated by scripting): This is highly unlikely since modern browsers and services already deprecated older versions of TLS. If this is an issue then you'd need to update the service (if the endpoint is an internally hosted service) or check the documentation for the service.

JDBC Drivers May Need Updating​

Due to updated Java versions, JDBC drivers for existing installations may need to be updated for compatibility. See the JDBC Drivers and Translators page for more details.

SFCs​

Due to the tag system changes, SFC parameters are no longer able to store entire QualifiedValue objects, such as those returned by the system.tag.readBlocking function. However fields of a QualifiedValue, such as the value, can still be stored in parameter. 

# No longer supported
chart.new_param = system.tag.readBlocking(["[default]myTag"])
 
# Supported
chart.new_param = system.tag.readBlocking(["[default]myTag"]).value

Webdev Endpoints​

In 7.9, Webdev resource endpoints resembled the following:

Legacy Endpoint
host:port/main/system/webdev/projectname

In 8.1, Webdev endpoints no longer contain "main":

8.1 Endpoint
host:port/system/webdev/projectname

Note that requests using the legacy endpoint will simply be redirected to the 8.1 endpoint, so endpoints created in 7.9 will still function after upgrading.

Tag Paths in Expressions​

Expressions that make use of a tag path will need to be updated to include either a tag provider or "[~]". 

{Path/To/Tag}           // paths that look like this...
 
 
{[~]Path/To/Tag}        // ...should be changed to this.
{[MyProvider]Path/To/Tag}  // You could always explicitly state the provider too.

New Features​

Introducing Ignition Perspective​

Ignition Perspective is an entirely new visualization system, built from the ground up to allow you to create modern, high performance, and highly functional pure-web applications that can be viewed anywhere. Learn more about Perspective by visiting the Perspective pages in the User Manual, or the Inductive University.

Using Perspective without Upgrading​

The Ignition Perspective module is one of the most exciting new features of Ignition 8, offering an entirely new and innovative way to visualize data and deploy applications to mobile devices. Many users will want to begin leveraging this module right away, and will feel compelled to upgrade for that purpose.

It is important to understand how various Ignition features, in particular the Gateway network and remote services, can be leveraged to allow immediate usage of Ignition Perspective without the potential risk or disruption necessary to upgrade a running production Gateway.

As part of the base platform, the Gateway Network allows you to create connections between Gateways, including between 8 and 7. The Remote Tag Provider allows you to use Tags from one Gateway on another, including both realtime and historical values. Remote Tag Providers created in Ignition 8 targeting Ignition 7 Gateways will support reading, writing, real-time subscriptions, and Tag history queries. For more information, see the Tag Providers page.

Therefore, to develop and deploy Perspective applications with minimum impact on your production system you can:

  1. Install Ignition 8 onto a different computer or VM instance.
  2. Limit the installation to the Perspective module (though, of course, other modules can be used).
  3. Create a Gateway network connection between the Ignition 8 Gateway and the Ignition 7 Gateway.
  4. Create a Remote Tag Provider on the Ignition 8 system for each provider you’d like to access.

Unless previously changed, remember that the Ignition 7 Gateway will employ the default “service security” settings for the remote Tag Gateway network service. This will allow read only data, but if you want to support writes, you’ll need to change the policy by going to Configure>Security/Service Security in the Gateway.

Introducing Identity Providers​

Ignition 8 adds support for connecting to SAML and OpenID Connect Identity Providers. In addition, Ignition can act as an Identity Provider, using a User Source as a backing source of users. On upgrade, a new Ignition Identity Provider will be created that points to a single user source, allowing users in that user source to authenticate against the Identity Provider. You can learn more about this on the Configuring Identity Providers page.

For more information, see the Gateway Authentication with Identity Providers section in the 8.0 to 8.1 Upgrade Guide.

Introducing Identity Providers also introduced the option to log in with RFID and badges starting in Ignition 8.0.5. This, in turn, required a new column called "badge" to be added to the *users table. When upgrading Ignition while your User Sources are set to "Automatic" Mode, this column will be created by default. If you are running into an issue with your User Sources, check to see if the "badge" column has been created.

System Commissioning​

Upon installing Ignition, the user is now presented with a “system commissioning” web based walkthrough. This process must be completed for new installations, and requires that an initial user is created for the newly commissioned Gateway.

As of Ignition 8.0, there is no longer a pre-defined default “admin” user. System administrators should choose a secure root username and password for optimal system security.

Security Levels​

Ignition 8 introduces the concept of Security Levels, which are abstracted attributes that can be given to users, and used as a means to restrict access to different parts of the system. Security Levels can be assigned to users based on User Roles, Security Zones, a combination of both, or neither, as the Expression Language can be used to determine which level any given user falls under.

Many subsystems in Ignition will automatically migrate over to security levels upon upgrade, such as Tag read and write permissions.

Expanded Auditing Scope​

Ignition's built-in auditing system was very limited in version 7, recording only a handful of events. Most events that registered in the system had to originate from a project, so changes made at the Gateway level were largely ignored, save for Tag writes.

In Ignition 8, the auditing system's reach has broadened greatly. The system now accounts for configuration changes made at the Gateway level. Check out the Auditing Actions Reference page for a full listing of actions that are audited.

Project Resource Storage​

The new project subsystem in Ignition 8 uses a new file-based storage strategy, instead of the internal-database strategy used in Ignition 7. This has several significant benefits over the previous methodology:

  1. All resources can now be tracked with industry standard source control tools, such as Git. Resources can be tracked individually, and changes to disk caused by source control operations (checkout, pull, etc.) will be applied automatically to the running system.
  2. Project resources can be transferred between systems with simple file system operations. System administrators can use a wide range of tools to synchronize all types of resources between Gateways.
  3. Project backups are simply standard zip files organized in the same way as the file system.

Designer Concurrent Editing and Conflict Resolution​

Ignition 8’s Designer uses a new lock-free strategy for handling concurrent editing. We believe that this strategy is significantly more robust and will allow for more designers to work together on projects.

The Ignition 7 locking strategy is incompatible with the new file system storage strategy. Since changes can occur in the file system at any time, it isn’t possible to maintain exclusive edit locks in the Designer.

In Ignition 8, you may open and modify any resource in your project. You will be notified if the system detects that you and another user are both editing the same resource, or if the resource you’re editing has already been modified remotely. If you modify the resource anyway, and someone else has modified it first, this is called a conflict. The system automatically detects conflicts when you try to save. If any are detected, you are given the opportunity to resolve these conflicts by choosing whether to use your changes, accept the changes that happened elsewhere, or cancel your save and figure out what to do in another way.

Changes to Gateway Command Utility (GCU)​

As of Ignition 8.0, the Gateway Command Utility is deprecated. Functions similar to the ones found in the Gateway Command Utility are now run through the command line. You can find a list of available commands on the Gateway Command-line Utility - gwcmd page.

Last updated on by ia-sshamgar