Configuring Ignition Python Libraries Without NumPy

Patricia Callen5 min read
HMI / SCADAOther ManufacturerTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Ignition does not provide general compatibility with the CPython data-science ecosystem. Its scripting environment runs Jython on Java and uses Python 2.7 syntax. A library is a practical candidate only when its compatible release is written entirely in Python or Java and does not depend on CPython extensions or native C binaries. That excludes normal NumPy and pandas distributions from an in-process installation.

Treat the analysis path as a signal chain: identify the input data, confirm which runtime executes each transformation, and inspect the value delivered to the database, tag, report, or user interface. Measure that chain before rewriting calculations. Tuning does not fix a runtime boundary.

Which Python runtime is executing the analysis?

Start by separating the external analysis environment from the Ignition scripting environment. A script that runs under desktop or server CPython has not demonstrated compatibility with Jython. CPython extension modules use a native binary interface; Java-hosted Jython cannot load the C libraries used by high-performance CPython add-ons.

Record the interpreter used by the working external project, the selected package releases, and whether any installed files are native binaries. Then compare the package's declared Python compatibility with Python 2.7. The phrase “latest Ignition version” is not enough to select a package: read the scripting-runtime information for the installed Ignition release and test against that actual runtime.

Signal or reading Source Wrong-value symptom
Interpreter family and language level Runtime identification from the executing script Code works in external CPython but fails to parse or import in Ignition
Package dependency chain Package metadata and distribution contents A top-level import begins, then fails when a dependency loads a native extension
Input rows, types, and nulls Data immediately before transformation The library is blamed for a source-data or type-conversion problem
Calculated output Value immediately after transformation Downstream tags, reports, or displays receive missing or malformed results
Execution duration and failures Repeated test runs and application diagnostics A correct calculation is operationally unusable because it blocks, times out, or fails intermittently

Does the library require CPython or native C code?

Inspect the complete dependency tree, not just the top-level package. If the package or any required dependency contains a compiled CPython extension, stop the in-process installation path. NumPy relies on native components, and typical pandas distributions depend on NumPy; copying their package directories into Ignition does not remove that dependency.

If every dependency is pure Python, locate a release that still supports Python 2.7 syntax. That is a compatibility candidate, not a guarantee. Imports may still depend on CPython-specific standard-library behavior, unsupported platform services, or dynamic features that differ under Jython. Run an import test and a representative calculation before accepting the package.

A successful package installation in a separate CPython environment proves only that CPython can load it. Likewise, a successful top-level import is incomplete verification because some packages load optional or native modules only when a particular function executes.

What calculation does the process actually require?

Look at the trend first. Identify the exact operation: descriptive statistics, matrix arithmetic, filtering, grouping, reshaping, or model execution. This determines whether Ignition needs a library at all.

For mathematical and statistical functions available in Java, use Apache Commons Math from Jython. Java classes are a natural fit for a Java-hosted runtime and avoid the CPython native-extension boundary. For straightforward data manipulation, Jython list comprehensions and explicit loops can replace limited dataframe operations. The Simulation Aids module is another option when its functions match the required manipulation.

Keep the replacement proportional to the calculation. Rebuilding a dataframe engine in project scripts creates more maintenance risk than moving a genuinely dataframe-heavy workload to the environment designed to execute it.

Should the calculation remain inside Ignition?

Use this branch after classifying the dependencies and workload:

  1. If the library requires a CPython native extension, run the analysis outside Ignition.
  2. If the calculation maps cleanly to Apache Commons Math, Java collections, or short Jython transformations, keep it in Ignition and test the result against a known dataset.
  3. If a pure-Python package supports Python 2.7 and all dependencies are also pure Python, stage it for an isolated compatibility test.
  4. If the workload already runs correctly outside Ignition, expose that calculation through an API. Send defined inputs from Ignition and return a small, versioned result payload.

For the external branch, define the interface before connecting production data. Specify field names, types, null handling, units, request limits, error responses, and the identity of the calculation version. The external service owns CPython, NumPy, pandas, and their binary dependencies; Ignition owns acquisition, request orchestration, result validation, and delivery to the final consumer.

How should a pure-Python candidate be tested?

Use a controlled procedure rather than copying a package directly into an operating project:

  1. Record the Ignition release and identify its embedded scripting runtime.
  2. Select a package release that explicitly supports Python 2.7.
  3. Expand the full dependency tree and reject any branch requiring native C or CPython extension binaries.
  4. Make the package available through the supported scripting-library mechanism for the installed Ignition release.
  5. Restart or reload only as required by that mechanism, then capture the complete import error if loading fails.
  6. Execute the exact functions needed by the project using a fixed dataset with known outputs.
  7. Test nulls, empty inputs, unexpected types, and the largest normal dataset.
  8. Measure execution duration and review application diagnostics during repeated runs.

Do not modify calculations to hide an import failure. An import or linkage error occurs before the controller logic can act on the data; changing formulas cannot correct that layer.

How is the resolving design verified?

For an in-process Java or pure-Jython solution, compare each intermediate value with the known reference result. Confirm row counts, numeric types, ordering, null treatment, and final units. Repeat the test after a clean runtime start so success does not depend on a previously loaded module.

For an external API, test the whole loop: capture the input generated by Ignition, inspect the service response, validate the returned schema, and confirm the final element receives the intended value. Exercise service-unavailable, timeout, invalid-response, and stale-result paths. The application must distinguish a valid calculated zero from no result.

Preserve the reference dataset and expected outputs as a regression test. Re-run it whenever Ignition, the external interpreter, or any analysis package changes.

FAQ

Can I install NumPy directly in Ignition?

No. Normal NumPy packages use native components built for CPython, while Ignition scripting runs Jython on Java.

Can I use pandas in an Ignition script?

Not through the normal pandas distribution because it depends on NumPy and the CPython extension ecosystem. Run the dataframe work in an external CPython service and exchange inputs and results through an API.

Does every pure-Python 2.7 library work in Jython?

No. Python 2.7 compatibility and the absence of native extensions make a package a candidate, but its complete imports and required functions must still be tested under the installed Ignition runtime.

When should I stop testing and contact official support?

Stop when a pure-Python candidate passes dependency review but fails within the documented scripting mechanism, or when the installed release's runtime behavior is unclear. Capture the Ignition release, complete exception, minimal reproducing script, dependency list, and restart-state result, then escalate through the official Ignition support channel.

Back to blog