Hello,
I am investigating a reproducible RS-485 receive problem between a Larnitech DW gateway and an AOK motor. I would appreciate hypotheses with distinguishing tests, especially concerning UART receive handling immediately after transmission.
Setup: 2400 baud, 8N1, proprietary AOK protocol (not Modbus). An independent USB-RS485 adapter records the shared bus. Only read requests were used; no movement commands. Request: 9A 01 01 00 CC 00 CC Example complete motor reply: D8 01 01 00 12 18 00 12 02 1A FF Example delivered to the DW script: D8 00 12 18 00 12 02 1A FF The first D8 remains; the following two 01 bytes are missing.
Observed comparisons: A) DW sends, Echo OFF: five requests, five complete 11-byte motor replies in the independent capture; five 9-byte replies in the DW script callback. B) PC adapter sends, DW listens passively: five trials; DW callbacks contain the complete 7-byte request plus 11-byte reply (18 bytes). This changes both the transmitter and callback grouping, so it does not isolate the mechanism by itself. E) DW sends, Echo ON: DW callbacks still contain 9 bytes. The independent recorder sees request (7), full reply (11), then an additional 9-byte sequence matching the DW callback. We have not established which device transmits that additional sequence or the exact semantics of the Echo setting.
The diagnostic script reports the received length and copies bytes before logging; two reads agree. This is evidence about the API-delivered data, not an independent measurement inside the UART. If the retained D8 belongs to the same reply, simple loss of a contiguous prefix does not fully explain the pattern.
With the motor disconnected, a PC one-shot responder produced complete 11-byte DW callbacks both with a nominal 50 ms delay and with no deliberate delay (one trial each). USB/host timing was not measured electrically, so this does not establish a zero-gap response or a safe delay threshold.
A separate Creatrol sensor integration at 9600/8N1 improved from 0/5 complete callbacks to 5/5 after configuring the sensor reply delay from 0 to about 50 ms, with the script unchanged according to the project record. This is an analogy only: it does not prove the same cause or an equivalent AOK setting.
DW identification: model 135, firmware shown as 2023-09-14 Alpha v2. Protocol setting is disabled; built-in termination was OFF. Exact adapter internals, external termination/bias and physical turnaround timing remain unverified. I do not currently have an oscilloscope or logic analyzer.
Which mechanisms could retain D8 yet remove the next two bytes only after DW transmission? What minimal controlled tests would distinguish receive masking/echo handling, UART buffering/API behavior, and electrical turnaround issues? What result would each hypothesis predict?
For transparency, this same investigation is also discussed on PLCtalk and ELECTRONIX; I will cross-reference useful findings rather than treat them as independent evidence: https://www.plctalk.net/forums/threads/rs-485-gateway-receives-complete-replies-passively-but-loses-two-bytes-after-its-own-request.150149/ https://electronix.ru/forum/topic/228601-rs-485-posle-tx-sohranyaetsya-pervyy-bayt-otveta-no-ischezayut-sleduyuschie-dva-passivnyy-rx-polnyy/
Thank you.