A DL06 on Port 2 can miss an encoder response when the ladder waits for PRINTV to complete before enabling AIN; first prove the request bytes and port settings, then arm reception early enough to catch the reply. Treat the stated Z request and 10-byte response as protocol details to verify against the encoder manual: the request may mean one character or two, and that difference changes the transmit length.
Stop relying on the send-complete bit to start reception
A fast serial reply can arrive before the PLC scan reaches the rung that enables AIN. The send instruction completing is not proof that the encoder has not already started transmitting. A receive instruction that is inactive during the response can miss bytes even when the transmit operation itself succeeds.
Do not use a claimed baud-to-character interval as a substitute for checking timing. Baud rate alone does not establish the complete character time; framing contributes bits per character. Configure and reason from the encoder’s actual baud and framing, then make sure the receive operation is active before or at the same time as the request, if the DL06 instructions permit that sequence.
| Observed symptom | Likely cause to test | Discriminating check |
|---|---|---|
| No value appears in the receive destination | Receive was not armed in time, port setup is wrong, or no valid response reached Port 2 | Monitor transmit and receive activity, then test the encoder directly from a PC |
| The request appears only at startup | The transmit rung is enabled only on the Program-to-Run transition | Trigger PRINTV manually with a separate control bit |
| Some bytes appear, or data is misplaced | Incorrect request length, receive destination overlap, or byte-order mismatch | Capture the transmitted bytes and inspect the destination allocation |
| Communication works on a PC but not through the PLC | PLC port configuration, cable pinout, or ladder sequencing differs | Compare the PC test settings and verify TXD/RXD path at the PLC connection |
Check: Identify whether the current logic starts reception only after send completion. If it does, plan to arm reception concurrently with or before transmission rather than treating a rung-order change as proof of a working transaction.
Configure Port 2 for the encoder’s serial format
The port must use the encoder’s baud rate and framing, and it must be configured for Non-Sequence operation for the described ASCII instruction approach. In DirectSoft, the cited setup path is PLC/Setup/Setup Secondary Comm Port. Do not guess the port format from the PLC program: compare every setting with the encoder manual.
RTS and CTS also need a valid arrangement. In the described installation they were shorted; alternatively, the device can control them if the interface and device are wired and configured for that method. A jumper is not a universal substitute for checking the actual cable and device handshake requirements.
- Read the encoder manual for baud, data bits, parity, stop bits, and any flow-control requirement.
- Set Port 2 to the matching format and Non-Sequence mode in the secondary communication-port setup.
- Verify the RTS/CTS arrangement at both ends against the interface wiring and encoder requirements.
Check: Record the PLC and encoder settings side by side. Continue only when they match and the handshake wiring matches the chosen flow-control method.
Prove what PRINTV actually transmits
The notation 'Z ' is ambiguous: it can be read as a Z followed by a space, while the intended command may be a single Z character. The transmit length must match the encoder protocol exactly. A one-byte instruction cannot send a two-character request. Confirm the expected literal command, byte count, and any required terminator in the encoder manual before changing the ladder.
Check the data representation as well as the count. The request stored for PRINTV may occupy more than one PLC memory location, and a byte-swap option can change which byte the device sees first. Use the instruction’s documented storage and swap behavior; do not enable byte swapping merely because the encoder response looks wrong.
- Write down the exact request as bytes, including spaces or terminators required by the protocol.
- Compare that sequence with the source data and the transmit length configured in
PRINTV. - Use a serial monitor on Port 2 to capture the request and verify its byte order and count.
Check: The captured request must match the encoder’s specified command byte-for-byte. If it does not, correct the source data, length, or byte-order setting before investigating the receive buffer.
Separate PLC transmission from encoder response
Use a PC serial terminal as an isolation test, not as a replacement for validating the PLC program. First connect the terminal to Port 2 and observe whether the PLC emits the request when commanded. Then connect the PC directly to the encoder using matching serial settings, send the verified request, and check whether the encoder returns the documented response length.
If the PLC’s request is visible at its port but the encoder does not respond through the installed cable, inspect the cable pinout. TXD and RXD may be crossed incorrectly; verify the interface pinout before swapping conductors. If the direct PC-to-encoder test also fails, return to the command bytes, serial format, and encoder protocol instead of repeatedly editing PLC rungs.
Watch the DL06 communication LEDs during a controlled test. Counters on the logic’s send- and receive-complete bits, identified in the described test as C3 and C4, can show whether the instructions complete. They do not prove that received bytes are correct, so compare them with a serial capture and the memory destination.
Check: Establish separately whether the PLC sends the right bytes and whether the encoder answers a PC with those same bytes. This identifies which side of the cable or protocol boundary needs correction.
Arm AIN before the encoder can answer
Arrange the ladder so reception is enabled before or at the same time as the request, rather than starting AIN only after PRINTV completes. The exact rung arrangement must follow the DL06 instruction semantics and the encoder’s response timing. If the encoder replies immediately, a sequential send-then-receive arrangement leaves a race window in which the PLC is not listening.
Control PRINTV with a separate bit during commissioning so the request can be triggered deliberately. Monitor the instruction status and LEDs while observing the receive destination. This also reveals whether the transmit condition is only true at the Program-to-Run transition, a setup that produces one request rather than repeated polling.
Allocate separate, adequate memory for transmit source and receive destination. The historical ladder suggestion was to use V2004 as the AIN destination because the request data at V2001 might use V2001 and V2002. Verify the actual operand width and memory use in the DL06 instruction documentation; do not assume those locations or widths apply to a different program. Overlapping source and destination data can corrupt the request or obscure the response.
- Reserve the transmit source and receive destination so they do not overlap.
- Make the receive instruction active before or concurrently with the controlled transmit trigger, subject to instruction behavior.
- Request the protocol-defined response length and observe the completion state and destination data.
Check: A controlled request produces the expected receive-complete indication and the expected number of response bytes in the reserved destination. If completion occurs without valid data, inspect the serial capture and buffer mapping rather than assuming success from the bit alone.
Rearm AIN for every transaction
A receive instruction that completes once and remains done or disabled may not capture later replies. For repeated polling, reset or otherwise rearm AIN according to its documented behavior after its completion bit C4 goes high. Build an explicit transaction cycle: issue the request, capture the response, process or copy the data, then rearm for the next request.
Do not reset the receive instruction before the completed data has been processed or copied. Conversely, do not leave it in a one-shot state and expect it to keep collecting subsequent replies. If the encoder sends only one response per request, each new read requires a new correctly timed request and a newly armed receive operation.
Check: Trigger at least two controlled transactions. Confirm that each request produces a new completion and fresh data, rather than one successful read followed by a permanently idle receive instruction.
Verify the complete request-response cycle
Run the finished logic with the port configuration, cable, data allocation, and receive sequencing established above. Verify at the wire and in PLC memory: a correct request leaves Port 2, the encoder returns the protocol-defined response, and AIN places those bytes in the intended destination. A memory value alone is insufficient if it may be stale from an earlier scan.
- Trigger a request and capture the transmitted bytes.
- Confirm the response byte count and content against the encoder protocol.
- Check the receive-complete state, destination data, and a subsequent transaction after rearming.
- Confirm operation continues after the PLC enters Run and is not limited to the Program-to-Run transition.
Check: The repeatable pass condition is a correct transmitted command, a correctly sized valid response, fresh destination data, and another successful read after the receive instruction is rearmed.
Frequently asked questions
Why does the DL06 transmit but receive no encoder data?
The response may arrive before AIN becomes active if the ladder waits for PRINTV completion. Arm reception before or concurrently with transmission, then verify the response at Port 2 and in the receive destination.
Why does the encoder ignore the DL06 Z command?
Check whether the protocol expects one Z byte or Z plus a space, and make PRINTV send the exact required byte count and order. Verify the captured request, baud and framing, and cable TXD/RXD path.
Why does the DL06 read only once after switching to Run?
The transmit rung may be triggered only on the Program-to-Run transition, or AIN may not be rearmed after C4 completes. Use a controlled trigger and explicitly rearm the receive operation for each transaction.
When should I stop and contact official support?
Stop changing firmware or ladder logic if the PLC emits the verified request, the encoder’s direct PC test works, and Port 2 still does not receive valid data with matching settings and wiring. Provide official support with the DL06 model and firmware, port configuration, cable/interface details, ladder sequence, and serial captures; do not treat an unrelated firmware report as a confirmed fix.