[QUESTION]: SP700 dot matrix: PrintingTimeout on large multi-copy jobs causes duplicate prints via retry — guidance on SDK-native solution?

[dgreasi]

Description

Environment

• react-native-star-io10 version: 1.12.1
• Printer model: Star SP700 (dot matrix)
• Interface: LAN (both WiFi and wired Ethernet)
• Platform: iOS and Android

Problem

When printing a large number of tag copies in a single job (typically 15+ total copies across multiple tag types), the SP700 takes longer than expected to process the full command set. The SDK returns a PrintingTimeout error from printer.print(commands) before the printer has finished.

The core issue is that this timeout fires after print data has already been transmitted to the printer's buffer. The printer continues printing physically, but the app treats it as a failure. Any retry mechanism then sends the same job again, causing duplicate physical prints — which is the bug our users are experiencing.

Observed behaviour

• Orders with 15+ tag copies across multiple tag types trigger the timeout
• Printer pauses mid-job and then continues unexpectedly (retry fired while first job still in printer buffer)
• Tags for a completed order reprint minutes later (retry delay of 5–20s fires while user is on a different order)
• Reported more frequently on iOS

Our current workaround

We chunk tagDetails into groups where the total suggested_copy_value per chunk is ≤ 8, with a 300ms delay between chunks and a single printer.open() for the entire job:

const MAX_COPIES_PER_CHUNK = 8;
const CHUNK_DELAY_MS = 300;

await printer.open();
for (let i = 0; i < chunks.length; i++) {
const builder = printerSetup.print(order, template, { ...localPrinter, tagDetails: chunks[i] });
const commands = await builder.getCommands();
await printer.print(commands);
if (i < chunks.length - 1) await sleep(CHUNK_DELAY_MS);
}

This avoids the timeout for individual chunks. However it introduces new failure modes:

• If a chunk fails mid-way through, earlier chunks have already physically printed. A retry from chunk 0 over-prints those.
• The 300ms inter-chunk delay was chosen empirically — we have no basis for whether this is appropriate for the SP700.

We have since disabled retries for all errors except StarIO10InUseError (where no data has been transmitted) to prevent duplicate prints.

Questions

1. Is there a recommended SDK-native approach for large multi-copy dot matrix jobs? We haven't found any guidance on this in the documentation or closed issues.
2. Does the SP700 support the spooler function (print(commands, StarSpoolJobSettings))? The model support page was not accessible at time of writing. If it does, would the spooler handle large jobs better than sequential chunked calls?
3. Is there a way to determine whether print data was successfully received by the printer before a PrintingTimeout is thrown? This would let us distinguish "data sent but ack lost" (no retry safe) from "data never reached the printer" (retry safe).
4. What is the recommended discoveryTime for a mixed WiFi/Ethernet LAN environment? We raised ours from 2500ms to 10000ms after consistently failing to discover an Ethernet-connected printer. Is 10s the right order of magnitude?

Type of question

Printer behavior / status / error handling

Related platform(s)

iOS, Android

react-native-star-io10 version

1.12.1

react-native version

0.83.1

react-native-windows version (Windows only)

No response

Target device (if applicable)

No response

Target device OS version (if applicable)

iOS & Android

Printer model (if applicable)

SP700

Printer firmware version (if applicable)

No response

Printer interface (if applicable)

Ethernet

Host OS (development machine)

macOS

Host OS version

No response

Output of npx react-native info (optional but helpful)

System:
  OS: macOS 26.5.1
  CPU: (12) arm64 Apple M2 Max
  Memory: 116.64 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.22.3
    path: ~/.nvm/versions/node/v22.22.3/bin/node
  Yarn:
    version: 1.22.22
    path: ~/.nvm/versions/node/v22.22.3/bin/yarn
  npm:
    version: 10.9.8
    path: ~/.nvm/versions/node/v22.22.3/bin/npm
  Watchman:
    version: 2025.10.20.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/dimitrisgreasidis/.rvm/gems/ruby-3.3.2/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 25.5
      - iOS 26.5
      - macOS 26.5
      - tvOS 26.5
      - visionOS 26.5
      - watchOS 26.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2026.1 AI-261.23567.138.2611.15646644
  Xcode:
    version: 26.5/17F42
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 21.0.10
    path: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/javac
  Ruby:
    version: 3.3.2
    path: /Users/dimitrisgreasidis/.rvm/rubies/ruby-3.3.2/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.2
    wanted: ^20.0.0
  react:
    installed: 19.2.0
    wanted: 19.2.0
  react-native:
    installed: 0.83.1
    wanted: 0.83.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

info React Native v0.86.0 is now available (your project is running on v0.83.1).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.86.0
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.83.1&to=0.86.0
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".

What have you tried so far?

No response

Code snippet (optional)

Additional context

No response

Pre-submission checklist

• I have searched existing Issues for similar questions.
• I have read the relevant sections of the README and the StarXpand SDK documentation.

[bandit-ibayashi]

@dgreasi Thank you very much for the detailed report and your patience.

Due to the difference in mechanism, printing on the SP700 inevitably takes longer than on direct thermal printers. In addition, because communication between the host device and the SP700 is over LAN (both wired and wireless), any traffic delay or packet loss for whatever reason will also add time.

The print() function of StarPrinter first checks the printer's status to see whether conditions such as paper-out or cover-open have occurred. It then sends the print data, and finally the method finishes execution only after confirming that printing has completed. The timeout set by the printTimeout property starts counting when the print() function is called; if the timeout period elapses, it ends that function's processing and returns an error.

For this reason, if data transmission from the host device has completed but arrives at the printer with a delay, and as a result the print processing does not finish within the time specified by printTimeout, an error occurs on the host device side, yet the print data still reaches the printer—so there are cases where printing ultimately completes.

With that in mind, I would like to answer your questions.

1. Is there a recommended SDK-native approach for large multi-copy dot matrix jobs? We haven't found any guidance on this in the documentation or closed issues.

Since this involves a large number of multi-copy prints, I understand that your intent is to print all of this data together at once. On this point, I believe the approach of calling printer.open() only once for the entire job is preferable. If you open and close for each individual job, there is room for other print jobs to be inserted in between, which could result in an unintended ordering.

On top of that, one approach is to perform error handling for each repeated printer.print() call. If it simply failed to complete within the time due to delay or similar, the Code of StarIO10UnprintableError will be PrintingTimeout, so in the case of this error you could retry without closing and opening, and, if possible, when printing has already completed you could retry from the next job onward—this way I believe you can also avoid duplicate printing.

In the case of DeviceHasError from StarIO10UnprintableError, similarly, without closing and opening, if you can remove the error cause such as cover-open or paper-out, I believe you can recover by calling print() again; however, for other Codes I believe you need to close once. In this way, I believe you can classify the handling by using the error and its Code.

2. Does the SP700 support the spooler function (print(commands, StarSpoolJobSettings))? The model support page was not accessible at time of writing. If it does, would the spooler handle large jobs better than sequential chunked calls?

Unfortunately, the SP700 does not support the print(commands, StarSpoolJobSettings) function.

3. Is there a way to determine whether print data was successfully received by the printer before a PrintingTimeout is thrown? This would let us distinguish "data sent but ack lost" (no retry safe) from "data never reached the printer" (retry safe).

This distinction is also, unfortunately, difficult. Because the OS-side buffer is used as well, one contributing factor is that when the data is outside the region the application can control, it cannot be controlled by the application. To improve the likelihood of making this distinction, I currently consider it best to set a printTimeout that takes into account the print time of a single job. Since the printTimeout duration resets with each print() execution, one idea is to set and control an appropriate time on a per-job basis. This appropriate time depends on the length of the job (the amount of data) and the environment, so it is difficult to state a single definitive value.

4. What is the recommended discoveryTime for a mixed WiFi/Ethernet LAN environment? We raised ours from 2500ms to 10000ms after consistently failing to discover an Ethernet-connected printer. Is 10s the right order of magnitude?

In the StarXpand SDK (react-native-star-io10), the time required to discover a printer has been shortened, so I believe there is a high likelihood that a printer can be found even with a discoveryTime of 2500 milliseconds. On the other hand, depending on the environment it may take longer, so I also believe there is no problem with setting it to 10000 milliseconds. This is because, by ending the search once the specified printer is found, I believe you can achieve both securing a sufficient timeout period and reducing the actual search wait time that users face.

If you have any questions, please feel free to let us know. Thank you for your continued support.