Resolving Trajexia TJ1 32-bit Hostlink Float Exchange on Omron

Problem Overview

Engineers integrating a Omron Trajexia TJ1-MC16 motion controller with an Omron NT3S series HMI over the Hostlink (SYSWAY/C-mode) serial protocol frequently encounter a 32-bit data corruption symptom. 16-bit INT values round-trip cleanly between the HMI's VR (Value Register) memory and the controller's VR table, but any 32-bit REAL or DINT value splits across two consecutive 16-bit registers in a way that the receiving device cannot reconstruct.

The classic failure signature is: a floating-point number written to VR(300) on the HMI appears on the controller as two consecutive 16-bit words with the high half in VR(300) and the low half in VR(301). Reading VR(300) as a single 16-bit value returns only the high 16 bits of the IEEE 754 representation, which is meaningless as a stand-alone integer and cannot be used directly in Trio BASIC arithmetic.

System Architecture and Components

For the canonical wiring and protocol parameters, consult the Trajexia TJ1-MC16 Programming Manual (I52E-EN) and the Trajexia Machine Control System Programming Manual (I58E-EN-05). Both manuals document the Hostlink slave implementation, the SETCOM instruction, and the HLS_NODE parameter.

Root Cause: Non-Standard Trio Floating-Point Format

The root cause is not a bug in either device. It is a floating-point byte-order mismatch between two otherwise IEEE 754-conformant implementations. The Trajexia firmware stores a 32-bit real in a non-standard order:

Because Hostlink exposes only 16-bit integer registers (VR), the four bytes of a Trio float arrive as two raw 16-bit words. Any consumer that interprets them as IEEE 754 will see a corrupted value. Performing arithmetic on the corrupted value produces drift, and comparisons (IF value > threshold) misfire because the bit pattern of a positive number can decode as a negative or out-of-range value.

There is no Hostlink register type code that signals "this is a 32-bit real"; the protocol simply does not carry type information. The NT3S side always packs the 32-bit REAL into two 16-bit words in IEEE 754 order, while the Trajexia side expects them in Trio order.

Hostlink Protocol Limitations on 32-bit Data

Hostlink (also called SYSWAY or C-mode) is a 1970s-era command-response protocol that operates strictly on 16-bit RD / WR word reads and writes. The following are the only legal operations on the TJ1 as a Hostlink slave:

• RR / WR — read/write a single CIO/IR/HR word
• RD / WD — read/write a single DM/VR word
• RH / WH — read/write the high/low byte of a word

There is no RL / WL 32-bit block primitive, and no "float read" command. The VR() table on the Trajexia is internally stored as 16-bit entries for the purposes of Hostlink access, even when the application uses them as halves of a 32-bit value. This is why the high half appears in TABLE(0) and the low half in TABLE(1) after a write of an IEEE 754 single.

Solution 1: IEEE_IN and IEEE_OUT Conversion in Trio BASIC

The supported workaround is to keep the HMI side in IEEE 754 (which the NT3S cannot change), but reconstruct the value on the controller side using Trio's byte-extraction instructions and IEEE_IN. The instruction takes four bytes in IEEE 754 order and returns the Trio-format floating-point number that the rest of the application can use.

The companion instruction IEEE_OUT performs the reverse: it accepts a Trio-format float and returns four bytes ready to be packed back into two 16-bit words for the HMI. Together, they form a software endianness and field-order shim sitting between the Hostlink register and the application variables.

Conversion Sequence for Reading an HMI-Written REAL

1. The HMI places the 32-bit IEEE 754 single in VR(300) (low word) and VR(301) (high word).
2. The controller reads both words using VR(300) and VR(301) in a REPEAT loop.
3. Each word is masked to extract the high and low bytes.
4. The four bytes are passed in IEEE order (sign → exponent → mantissa) to IEEE_IN.
5. The resulting Trio-format float is stored in a VR slot that the rest of the program reads.

Reference Implementation

The following MotionPerfect program is a minimal, compilable example that pulls a 32-bit REAL from the HMI, converts it to a Trio float, and exposes it at VR(302) for the application:

\ Read a 32-bit REAL from the HMI (VR300 / VR301)
\ and publish the usable Trio-format value at VR(302)

TABLE(63999, 1)            \ reserve a small table

GOSUB comms_set             \ configure Hostlink port 1

REPEAT                      \ main loop

  \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  \ Extract the four bytes of the IEEE 754 single
  \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  hbhw = (VR(301) AND $ff00) / 256   \ high byte of high word
  lbhw = VR(301) AND $00ff           \ low byte of high word
  hblw = (VR(300) AND $ff00) / 256   \ high byte of low word
  lblw = VR(300) AND $00ff           \ low byte of low word

  \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  \ Reassemble as a Trio floating-point value
  \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  VR(302) = IEEE_IN(hbhw, lbhw, hblw, lblw)

UNTIL FALSE

\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ Hostlink slave configuration
\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
comms_set:
  HLS_NODE = 0              \ port 1 = Hostlink node 0, slave
  SETCOM(19200, 7, 2, 2, 1, 5)
  RETURN

Reverse Direction: Writing a Trio REAL to the HMI

To push a value from the controller back to the screen, use IEEE_OUT to obtain four bytes, pack two bytes into each of two consecutive VR words, and let the HMI read them in IEEE order. A typical sequence:

\ Source: Trio-format float in user_var
IEEE_OUT(user_var, hb_out, lb_out, hb_low, lb_low)

\ Pack high word
VR(310) = (hb_out * 256) + lb_out

\ Pack low word
VR(311) = (hb_low * 256) + lb_low

Solution 2: Replace the NT3S with an NS-Series HMI over Ethernet

Omron's official position is that the only clean way to pass Trajexia REAL values across the HMI boundary is to migrate to an NS5 (or NS8/NS10/NS12/NS15) with Ethernet and the dedicated Trajexia driver. This driver runs the IEEE 754 ↔ Trio conversion inside the NS runtime, so the screen presents a standard REAL to the tag database and no MotionPerfect conversion code is required.

NS-series HMI configuration uses CX-Designer or the corresponding Sysmac Studio tool; the Trajexia driver appears in the manufacturer list and exposes VR, TABLE, axis parameters, and the IEEE float registers directly. The full setup is documented in the TJ1-MC16 Programming Manual in the "Communication with NS-series HMI" chapter.

Handshaking: Distinguishing HMI Writes from Controller Writes

If the application must support bidirectional 32-bit transfer (operator changes a setpoint on the screen, controller also updates the displayed value, e.g. an actual-position echo), you must add a handshaking scheme. Without it, both sides will write to the same two VR words and the last writer wins, with no way to tell which side initiated the change.

A common pattern uses a third 16-bit word as a toggle:

\ HMI increments VR(399) every time the operator changes the setpoint
\ Controller compares the new toggle against the last-seen toggle;
\ on change, the controller reads VR(300)/VR(301), runs IEEE_IN,
\ and publishes the value into a Trio variable that the motion
\ program consumes. After consumption, the controller writes a
\ sequence counter to VR(398) so the HMI knows the value has
\ been latched.

Firmware and Software Versions

Bug-fix history on the NTXS configuration software has included several releases that changed how the NT3S encodes 32-bit values. Always confirm you are running the latest NTXS version available in the Omron download portal before attempting any of the workarounds above; older versions have been observed to encode the mantissa with an internal byte swap that the shim code in this article does not compensate for.

Verification Procedure

1. Connect the NT3S to the TJ1 with a known-good RS-232 cable (null modem or Omron's XW2Z-style depending on the NT3S port variant). Confirm the link LED is active on the HMI.
2. On the HMI, configure Hostlink to match SETCOM(19200, 7, 2, 2, 1, 5): 19200 bps, 7 data bits, 2 stop bits, even parity, node 0.
3. Compile and download the sample program to the TJ1. In MotionPerfect, open the Watch window and add VR(300), VR(301), and VR(302).
4. On the HMI, place a numeric entry field bound to VR300 and a numeric display bound to VR302 (use a 32-bit REAL tag).
5. Enter the value 1234.5 on the screen. The IEEE 754 encoding is 0x449A5000. In the watch window, VR(300) should read 0x5000 and VR(301) should read 0x449A. VR(302) should display 1234.5.
6. Enter -3.14159. The IEEE 754 encoding is 0xC0490FDA. Verify VR(300) = 0x0FDA, VR(301) = 0xC049, and VR(302) = -3.14159.
7. Add a motion command (e.g., MOVEABS(VR(302)) on a configured axis) and command the move from the screen. Confirm the axis moves to the commanded position by the indicated amount.
8. If any verification step fails, halt the controller, swap the two bytes within each word using an extra shift, recompile, and re-test. This isolates whether your NTXS build is byte-swapping within words.

Common Pitfalls and Diagnostic Matrix

Performance and Timing Considerations

At 19200 bps with 7E2, a Hostlink RD of one word requires roughly 33 ms including turnaround. Reading two words and the handshaking counter therefore takes around 100 ms per polling cycle. For closed-loop control, this is far too slow; the Ethernet NS-series path reduces the same cycle to single-digit milliseconds.

If you must remain on Hostlink, place the IEEE conversion in a fast background task triggered by the change counter rather than the main loop, and minimize the number of VR() reads per scan. Also keep VR(300)/VR(301) adjacent in the NT3S project so the byte order is unambiguous; the NT3S does not perform any byte reordering on its own.

Migration Checklist to Ethernet NS-Series

1. Replace the NT3S with an NS5, NS8, NS10, NS12, or NS15. Confirm the NS model supports the Trajexia driver; all current NS models do.
2. Add an Ethernet port connection between the NS and the TJ1. The TJ1-MC16 has a 10/100 Ethernet port on the front panel.
3. In CX-Designer (or Sysmac Studio NS edition), select the Trajexia driver and enter the controller's IP address.
4. Map screen numeric entry/display tags directly to the controller's VR or TABLE addresses. Set the tag type to REAL (32-bit IEEE 754).
5. Remove all IEEE_IN / IEEE_OUT conversion code from the MotionPerfect program.
6. Recycle power on both devices and download both projects.
7. Re-run the verification procedure from the previous section. All six value checks should pass without any byte manipulation in the controller.

FAQ