Search

User Manual

Getting Started


Modules and Platform


Appendix


Tutorials & Helpful Tricks


Glossary


Strategic Partner Links

Sepasoft - MES Modules
Cirrus Link - MQTT Modules

Resources

Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples

All Manual Versions

Ignition 8
Ignition 7.9
Ignition 7.8

Deprecated Pages

Skip to end of metadata
Go to start of metadata


Overview

Many users find a Development Server useful so changes can be tested in a safe environment before being pushed to production. This page details several recommendations and issues to consider when utilizing a Development Server. 

Device Considerations

  • The Development Server should have its own PLCs. This prevents the Development Server from accidentally writing to a Tag that the Production Server is connected to. 
  • Device connection names should be the same on both the Development and Production Servers. OPC Tags typically reference the name of the Device Connection in their OPC Item Path, so using the same name on both servers means that Tags can easily be migrated from one server to the other. 
  • Using PLC simulators is an alternative to the Development Server having its own PLCs. Generally this means finding simulators for your specific devices outside of Ignition.

Licensing Considerations

  • The Development Server does not require a licensed Ignition Gateway, but one may be necessary depending on your testing requirements. All modules can run on the trial for a two-hour testing window, and may be started an unlimited number of times. If you want a more flexible test system for your Development Server, you can add a license to it. 

Database Considerations

  • The Development Server should have its own database, separate from the production database. This is especially useful when designing screens that manually modify a database table. 
  • The names of the database connections used by the Development Ignition Gateway should match the names of the connections on the Production Server. Many system functions that interact directly with the database, such as system.db.runPrepUpdate, take the name of the database as a parameter, so using similar names for connections on both servers means you will not have to modify the script once it has been moved to the Production Server. 

Network Considerations

  • Some users prefer to place their Development Server on a separate network from the Production Server. This way there can be no confusion as to which server is being accessed. Keep in mind that Clients can only be launched on panels/computers that have network access to the host Gateway, so how this development network is configured will impact where testing clients can be launched. 
  • If you are restoring a copy of your Production Server on your Development Server, you will need to be cautious: two copies of the same Gateway, on the same network, will both have access to all PLCs and Databases. In this case it is possible for duplicate historical records to be generated, amongst other potential problems. To prevent this, we recommend keeping the Development Server on a separate network.
    Alternatively, you could utilize the Restore Disabled checkbox when restoring on the Development Server. Once the disabled Development Gateway is up and running, you can edit each connection and point them to testing equipment.

Transferring Resources from Development

  • When you are ready to move resources from the Development Server to the Production Server, Gateway Backups should not be utilized as they will include connections to the development resources. Instead, use the Project Exports and Tag Exports functionality to transfer resources. 
  • In cases where there are multiple Ignition Servers (Production or Testing), the Enterprise Administration Module can make the resource migration easier. 

On this page ...



  • No labels