Ignition and BarTender: Use Async Calls, Not ActiveX

Ignition can print on-demand tracking labels either through its Report Builder or by sending label data to BarTender. For a new integration, use a supported process boundary—HTTP or a raw socket—rather than trying to load BarTender ActiveX components into Ignition. Run blocking report or communication work asynchronously and treat printer output, response data, and timeout handling as commissioning checkpoints.

Integration Approach Comparison

Before anything else, confirm whether BarTender must remain the label-rendering system. That decision determines whether Ignition generates the finished label or only submits print data.

Use Ignition reports when replacing the label design is acceptable. When the customer must retain existing BarTender templates for DM and QR labels, keep BarTender as the rendering endpoint and send it data through HTTP or a raw socket. Direct ActiveX reuse is not the recommended migration path.

Recommended Integration Boundary

The preferred architecture separates the Ignition gateway from the Windows automation technology used by BarTender. Ignition assembles a print request containing the template selection, tracking values, printer destination, and a unique job reference. A BarTender-facing process accepts that request, invokes the established print workflow, and returns an acknowledgement or failure.

This boundary avoids loading incompatible runtime components into the gateway process. It also gives the integration a place to validate requests, serialize access when required, record job results, and isolate printer or BarTender failures from normal gateway execution.

Choose HTTP when the receiving component already exposes a request-and-response interface or when status codes and structured responses simplify diagnostics. Choose a raw socket when Commander or another established listener already accepts a defined message. Do not select the transport until the receiving interface is identified and a test request can be submitted outside Ignition.

Interface Prerequisites

Define the job contract before writing the gateway script. A successful network connection proves only that a listener accepted traffic; it does not prove that the correct label printed.

1. Identify the rendering owner. Set either Ignition Report Builder or BarTender as the only component responsible for layout. Confirm the choice by producing one known label manually.
2. Define required job fields. Record the template reference, DM or QR payload, human-readable tracking text, quantity, and printer selection required by the installed workflow. Confirm that the receiver rejects a request missing a mandatory field.
3. Define job identity. Include a unique request reference so retries and duplicate prints can be distinguished. Confirm that the same reference appears in the gateway log and receiving process record.
4. Define completion semantics. Decide whether the receiver acknowledges request acceptance, successful rendering, or physical print submission. Do not move on until operators and controls engineers interpret the acknowledgement the same way.
5. Define failure handling. Set the connection timeout, response timeout, retry policy, and disposition of an uncertain job from site requirements. Confirm each failure produces a visible result rather than an indefinitely waiting script.

Asynchronous Print Procedure

Both report generation and external communication can block the thread that calls them while rendering, network I/O, or printer submission completes. The control objective is to move that work away from the initiating event thread while retaining an observable job result.

1. Validate the request synchronously. Check required tracking data, label type, quantity, and destination before starting background work. Confirm invalid input returns immediately without contacting the print system.
2. Create the print job record. Mark the job as pending and attach its unique reference. Confirm the initiating client can display that reference before launching the worker.
3. Launch a background function. Call system.util.invokeAsynchronous() and place the blocking report or transport operation inside the invoked function. Confirm the initiating event returns without waiting for label generation or the network response.
4. Execute one print path. For an Ignition label, call system.report.executeAndDistribute() from the asynchronous function and target the label printer. For BarTender, perform the selected HTTP request or open the raw socket from Java/Jython and submit the defined message. Confirm that only one path handles each job.
5. Capture the terminal result. Record success, explicit rejection, timeout, connection failure, or an unexpected exception against the job reference. Confirm that every started job leaves the pending state.
6. Report status to the operator. Update the application through a shared job-status mechanism instead of attempting to return the eventual print result directly from the asynchronous call. Confirm the display distinguishes accepted, completed, failed, and uncertain outcomes.

Blocking and Concurrency Behavior

system.report.executeAndDistribute() blocks the thread on which it runs. That does not mean every gateway function stops; it means the caller remains occupied until the operation returns. Invoking it through system.util.invokeAsynchronous() gives the work its own execution thread and allows the initiating script to finish.

Asynchronous execution does not remove downstream limits. Multiple operator requests can still contend for the same printer, BarTender process, template, or network listener. Add admission control where concurrent jobs could interleave data or overwhelm the destination. The receiver must own any serialization requirement that depends on BarTender or printer behavior.

Avoid blind automatic retries after a timeout. A timeout can occur after the receiver accepted the job but before Ignition received the acknowledgement. Use the unique job reference to query or reconcile status before resubmitting; otherwise, a communications fault can produce duplicate tracking labels.

Commissioning Verification

1. Prove the normal path. Submit a known tracking value and confirm the expected template, DM or QR content, readable text, quantity, and printer destination.
2. Prove nonblocking operation. Start a print job while introducing a controlled response delay at the test receiver. Confirm the initiating Ignition interaction returns while the background job remains pending.
3. Prove input rejection. Remove one mandatory field and confirm no label prints, the job is marked failed, and the operator receives an actionable reason.
4. Prove loss of service. Make the test endpoint unavailable and confirm the connection or response timeout terminates the worker and clears the pending state.
5. Prove acknowledgement meaning. Compare the Ignition job result with the receiver record and printer output. Confirm that an accepted request is not displayed as a physically completed label unless the integration can observe that stage.
6. Prove duplicate control. Repeat a request using the same job reference and confirm the configured policy either rejects, reconciles, or deliberately reprints it.

Frequently Asked Questions