0
45

Written by

Jainam Shah
Follow
Question Jainam Shah · Feb 22

Ensemble ASTM Service: "Expected <ENQ>; got: <ETX>" and TCP Connection Stuck in "Connecting" via Moxa NPort 5110

#Ensemble

Hi everyone,

I am currently integrating a Sysmex analyzer with InterSystems Ensemble/IRIS using a Moxa NPort 5110. I have successfully verified the physical and serial layers, but I am facing two specific issues: a protocol sync error and a persistent TCP connection state.
Environment:
Interface: ASTM.

Gateway: Moxa NPort 5110 (TCP Client Mode).

Server: Ensemble Business Service (EnsLib.ASTM.Service.TCPService).

Port: xxxx.

Current Status & Observations:
Serial Layer: Verified. The Moxa "Async Monitor" shows RxCnt increasing when the instrument sends data. Hardware pins (DSR/CTS) are ON.

TCP Connection: The Moxa Monitor shows the state as "Connecting" rather than "Established." However, a manual PowerShell test from a remote PC can reach port xxxx, suggesting the server is listening.

The Error: When data does occasionally hit Ensemble, the Event Log records: Expected <ENQ>; got: <ETX>.

Network Discrepancy: Wireshark on the server shows traffic from a remote public IP (78.100.161.79) during manual tests, but zero traffic is captured from the Moxa’s expected path.

Moxa Configuration:
Baud/Parity: 9600, 8, N, 1 (Matches Instrument).

Operating Mode: TCP Client.

Packing: Currently experimenting with Packing Length 1 and Force Transmit 100ms to avoid buffering.

Questions:
Why would Ensemble report receiving an <ETX> (0x03) when the ASTM state machine should always initiate with an <ENQ> (0x05)? Could this be a serial framing/bit-shift issue at the Moxa level?

What would cause the Moxa to stay in "Connecting" while a PC on the same subnet can successfully establish a TCP handshake with the Ensemble server?

Are there specific EnsLib.ASTM.Service.TCPService settings (like Terminators or Ack Mode) that I should adjust to prevent the $zu(189) connection drops when the handshake gets out of sync?

Product version: Ensemble 2018.1
Discussion (1)0
Log in or sign up to continue

Comments

DC AI Bot · Feb 22 Bot

To address your concerns:

  1. Receiving **ETX** when expecting **ENQ**:
    • The issue of receiving <ETX> instead of <ENQ> (expected for ASTM communication initialization) may stem from the configuration of the ASTM business service or the behavior of the Moxa device. InterSystems Ensemble supports a setting where ASTM messages without explicit ENQ/EOT characters can still be processed. You may enable this by creating a subclass of your ASTM service and setting the parameter EOTOPTIONAL = 1 in the service's code. This adjustment allows the system to handle consecutive ASTM messages without enforcing strict ENQ/EOT delimiters 1.
  2. TCP connection stuck in "Connecting":
    • The persistent "Connecting" state of the TCP connection on Moxa could indicate a network routing or firewall issue. Since manual testing from a different PC to the Ensemble server works fine, it's worth investigating the configuration settings of the Moxa device and ensuring it is properly pointing to the target IP address and port of the Ensemble service. Additionally, check if there might be any firewall settings blocking the Moxa device's attempts to connect to the Ensemble server.
  3. Settings in **EnsLib.ASTM.Service.TCPService**:
    • The TCPService class in Ensemble can be configured with specific terminators and acknowledgment modes to handle ASTM protocol-based communication. For instance, the property Get Reply may need adjustment to control how ACK or NACK is expected or sent during message exchange. If ENQ-related issues persist, adjusting this setting to circumvent rigid expectations could be tested. However, note that proper handling of ASTM communication standards should align with the specifications of the connected device/system 2.

Sources:

1. Configuring the Production for ASTM

2. Ensemble is not giving back ACK after ENQ and closes with EOT.

0