Written by

Question Jainam Shah · Apr 12

EnsLib.EDI.ASTM.Service.TCPService — CELL-DYN Ruby Link Test fails with EOTOPTIONAL=1, instrument shows Status DOWN despite ACK being sent

Hello,

I am working on integrating a CELL-DYN Ruby hematology analyzer (Abbott) with InterSystems Ensemble using the ASTM E1394 protocol over TCP/IP via a Digi One SP serial-to-TCP converter. I am facing a persistent issue where the Link Test keeps failing on the CDRuby side and the Transmit button remains greyed out. I have overridden EOTOptional=1 in the service class file as Ensemble was not able to send ACK after ENQ. Now I am getting below logs like Machine sends ENQ, Ensemble sends back ACK and Machine sends EOT instead of STX.

Logs:
CDRuby → 05 (ENQ)

Ensemble→ 06 (ACK)

CDRuby → 04 (EOT)

Troubleshooting details:

• TCP connection between Digi and Ensemble is ESTABLISHED (confirmed via netstat)
• Ensemble is receiving ENQ from CDRuby and responding with ACK correctly
• Ensemble ASTM Business Service is started and listening on port 5017
• Windows Firewall rule for port 5017 is correctly configured
• Digi Serial Port Profile: TCP Sockets, TCP Client mode, Connect = Always, Service = Raw
• Digi Basic Serial Settings: 9600 baud, 8 data bits, 1 stop bit, no parity, no flow control
• Digi Advanced Serial Settings: Login required = OFF, Verbose messages = OFF, Force DCD = OFF
• Digi configured as TCP Client, Ensemble as TCP Server
• TCP connection is ESTABLISHED (confirmed via netstat)

Questions:

• Could EOTOPTIONAL=1 be causing Ensemble to mishandle the EOT that CDRuby sends after receiving ACK during the link test, causing CDRuby to timeout?
• Is there a specific parameter in EnsLib.EDI.ASTM.Service.TCPService that controls how quickly ACK is sent back to the instrument after ENQ — could there be a delay causing CDRuby to timeout?
• Are there any known issues with EnsLib.EDI.ASTM.Service.TCPService when the instrument connects via a Serial-to-TCP converter (Digi One SP) over a NAT/public IP?
• What is the recommended configuration for EnsLib.EDI.ASTM.Service.TCPService parameters (FRAMEVALIDATION, ACKMODE, SESSIONTIMEOUT etc.) for a CELL-DYN Ruby instrument?
• Is there a way to increase the ACK response speed in Ensemble to ensure it responds to ENQ within the LIS1 establishment timeout?

Product version: Ensemble 2018.1

Discussion (1)0

Add reply

Comments

DC AI Bot · Apr 12 Bot

Setting EOTOPTIONAL=1 enables InterSystems Ensemble products to receive ASTM E1394 messages not separated by ENQ/EOT control characters, allowing consecutive messages to run together on a TCP connection. It can impact how Ensemble interprets EOT after ACK is sent during link tests. This parameter should only be enabled if the device supports this mode; otherwise, it might cause miscommunication issues such as timeouts or incorrect connection status being displayed by the instrument 1 2 3.
To ensure timely acknowledgment processing, the Response Timeout setting in ASTM Business Services specifies the maximum wait time for replies before considering responses incomplete. Setting this parameter to -1 makes the system wait indefinitely, removing the risk of timeouts due to delays. Additionally, a subclass modification can be made with custom logic for response speed adjustments 1 4.
No specific known issues with the EnsLib.EDI.ASTM.Service.TCPService element involving NAT/public IP connections were found. However, since the communication involves a serial-to-TCP converter, ensure proper configurations of both the DIGI device and services. Ensemble prohibits business services from initiating transmissions outside Ensemble, meaning that components should be carefully paired and tested 5.
Recommended configurations include:
- Configuring Response Timeout to avoid undue timeouts.
- Using Get Reply settings based on instrument behavior—clear this if ACK replies are not provided by the external ASTM system.
- Other settings like FRAMEVALIDATION, ACKMODE, and SESSIONTIMEOUT can be set based on the format requirements and communication stability 4 1.
You may consider custom subclassing or parameter adjustments to improve ACK response speed. For instance, ensuring the proper setup and procedure in generating and replying to link test ACK messages through custom logic or faster processing logic in subclasses is essential. Network-level optimization (e.g., TCP ACK frequency settings at the OS level) should also be considered in the troubleshooting process for reducing acknowledgment delays 4 1 2.