# Intermittent duplicate label print jobs arriving in bursts — Ignition 8.3.1 **URL:** \ **Category:** Ignition\ **Created:** [November 10, 2026, 2:01pm UTC](https://forum.inductiveautomation.com/t/intermittent-duplicate-label-print-jobs-arriving-in-bursts-ignition-8-3-1/117800 "2026-11-10T14:01:08Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![marcin.przybyl](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@marcin.przybyl](https://forum.inductiveautomation.com/u/marcin.przybyl)\ **Post date:** [November 10, 2026, 2:01pm UTC](https://forum.inductiveautomation.com/t/intermittent-duplicate-label-print-jobs-arriving-in-bursts-ignition-8-3-1/117800/1 "2026-11-10T14:01:08Z")
Hello, I am troubleshooting intermittent duplicate label printing in a system running Ignition 8.3.1. Due to confidentiality requirements, I can only provide a generic technical description. The normal workflow is: - A scanner reads a product code once and correctly. - A tag-change script uses the identifier to retrieve label content from an API. - The label content is written to a tag. - A printing script sends the content to a network printer over a TCP socket. - The correct label is printed. This process runs continuously during automatic operation. Products are normally scanned approximately every **5–20 seconds**. **The issue is that, at some point, the printer receives a burst of 5–6 print jobs associated with previously scanned codes. All these jobs arrive within just 15–25 milliseconds.** The labels for these codes have already been printed correctly, and the corresponding products are no longer being processed by the machine. **The scanner does not scan these codes again.** We have not yet established whether old identifiers are being retransmitted or rewritten within the system, or whether previously retrieved label content is being sent again. Observations and checks so far: - A limited test involving only the final identifier reading and printing workflow completed without duplicates. - The issue has occurred during operation of the complete system. - Switching to another printer did not eliminate the issue in earlier tests. - Disabling a separate label-related script was followed by two runs without duplicates, but the issue later returned. This does not establish that script as the cause. - I checked the references to the `box_id` tag using Cross Reference and confirmed that it is used to trigger label printing in only one location. - Only one scanner is associated with this printer. We are trying to distinguish between three possible scenarios: 1. Old identifiers are being written to the triggering tag again. 2. Another script is sending previously used label content. 3. Previously received jobs are being retained or repeated downstream of Ignition. What diagnostic approach would you recommend to identify exactly where these repeated jobs originate? In particular, what information should be logged at the tag-change event and immediately before the TCP socket send to distinguish repeated tag events, overlapping script executions, and calls to the printing function from different locations? I can provide anonymized script excerpts and log samples if needed. Thank you. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 10, 2026, 2:13pm UTC](https://forum.inductiveautomation.com/t/intermittent-duplicate-label-print-jobs-arriving-in-bursts-ignition-8-3-1/117800/2 "2026-11-10T14:13:45Z")
1. Something is writing to tag properties and restarting the tag, causing its tag event to run again. Consider not using two scripts. That is, use a gateway tag event (in the project, not on the tag) to both call the API for the label content, and perform the print operation. (Neither of these is safe to use in tag valueChange events, anyways.) That eliminates the need for an intermediate tag for the label content. The script should use a memory tag to keep track of the last scan to avoid duplicates. You cannot trust `initialChange` and tag value comparisons when tag restarts might be involved. ---
**Author:** ![Noah\_Burnette](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/noah_burnette/32/83777_2.png) [@Noah\_Burnette](https://forum.inductiveautomation.com/u/Noah_Burnette)\ **Post date:** [November 10, 2026, 2:16pm UTC](https://forum.inductiveautomation.com/t/intermittent-duplicate-label-print-jobs-arriving-in-bursts-ignition-8-3-1/117800/3 "2026-11-10T14:16:27Z")
Hi Marcin, I would recommend uploading as much information as you can to give more context including scripts and logs. Make sure that any tag change scripts are filtering out `initialChange` and comparing the `newValue` with the `previousValue` to prevent duplicates/quality changes.