The FA-ISONET interface card prevented the DL06 from delivering commands to the stepper indexers because it held the transmit line high. Removing the card and connecting the PLC with the indexers’ working wiring restored communication; the laptop’s HyperTerminal display had been a misleading test of that network.
Stop changing ASCII formatting while the transmit path is suspect
When an indexer accepts a command from a laptop but ignores output from a DL06, it is tempting to keep changing command characters, port settings, or byte order. Those changes address the message or serial configuration, but they cannot correct a physical-layer condition that prevents the indexer from receiving the PLC transmission.
- Do not keep appending control characters as the first response. The DL06 output was visible in HyperTerminal, but the indexers still did not react. Visibility at the laptop did not prove that the indexer received the same signal.
- Do not add byte swaps without a specific data-format reason. Byte order can matter when a PLC formats multi-byte values, but repeatedly changing it does not fix an unavailable or held transmit line.
- Do not treat a laptop display as proof of correct field wiring. In this setup, the wiring that let the laptop see the PLC was not the wiring that allowed the indexers to receive from it.
- Do not leave the 422/232 interface card in the path simply because the laptop test needs it. The card’s presence in the network coincided with the indexers’ failure; removing it was part of the successful fix.
Freeze command-format experiments until the PLC-to-indexer path is isolated. Otherwise, every test changes multiple variables and can make a wiring or line-control fault look like an ASCII problem.
Separate the laptop symptom from the indexer failure
The test network connected the PLC, two indexers, a 422/232 interface card, and a laptop running HyperTerminal. The two observed results were not contradictory: the laptop could display PLC output under one wiring arrangement, while the indexers did not respond under that arrangement.
| Observation | What it demonstrates | What to check next |
|---|---|---|
| Indexer accepts ASCII sent from the laptop through the interface card | The indexer can accept at least that command path and format. | Compare the PLC’s actual transmit path and wiring; this does not validate them. |
| PLC output appears in HyperTerminal when wired “backwards” for that test | The laptop can observe output with that connection arrangement. | Do not copy that arrangement to the indexer network without checking the signal path. |
| Indexers ignore PLC commands while the interface card is on the network | The network path or line state is still suspect even if a monitor sees characters. | Remove the card from the PLC-to-indexer path and retest with the working PLC wiring. |
| Indexers respond after card removal and normal PLC wiring | The serial path is restored under that arrangement. | Keep the card out of the path and then verify repeatable command response. |
The key distinction is between observing characters and delivering a usable signal to the receiving device. A serial monitor proves only that its own receiver detects activity. It does not prove that another receiver sees valid levels, that the intended driver controls the pair, or that the network wiring suits both devices.
Recognize how a held RS-422 transmit line blocks reception
RS-422 uses differential signal pairs. A receiving device interprets the voltage difference across a pair; matching wire labels alone does not establish that the right transmitter reaches the right receiver or that the line is free to change state. A device or interface that keeps a transmit output asserted can interfere with other equipment sharing that signal path.
In this case, the reported cause was that the interface card held the transmit line high, apparently preventing another device from controlling the line. With the card in the network, the indexers did not receive commands. With the card removed and the PLC connected in the normal way used for the indexers, they worked. Treat this as a line-path and interface-isolation fault, not as proof that every FA-ISONET card or every RS-422 installation behaves this way.
RS-422 installations can use separate transmit and receive pairs, and multi-drop arrangements depend on the actual port and device design. Do not assume that all terminals labeled TX should connect like-for-like throughout a mixed-device network. Use the DL06 port documentation and indexer wiring diagrams to identify each driver, receiver, and pair. The successful connection in this installation is the reference to reproduce; do not infer a universal pinout from the description alone.
Isolate the interface card before rewriting the DL06 program
Use one controlled change at a time. Have the approved wiring information for the DL06 port and indexers available, and power down equipment before moving serial conductors if the equipment instructions require it. Do not short, tie together, or hot-switch signal conductors to test a theory.
- Record the present network connections, including the PLC, each indexer, the 422/232 interface card, and the laptop connection. Mark the transmit and receive pairs as identified on the equipment, not by assumed cable color.
- Temporarily remove the 422/232 interface card from the PLC-to-indexer communication path. Keep the laptop monitor disconnected if it must remain in that path for the display to work.
- Connect the PLC to the indexers using the “normal” wiring arrangement that produced successful indexer communication in this installation: matching the corresponding TX and RX pair labels as documented for the equipment. Confirm the actual terminal definitions against the manuals before energizing.
- Send the same known command that previously worked from the laptop, using the current PLC program and port configuration. Avoid changing command text, byte order, and wiring in the same test.
- If the indexers still do not respond, stop and verify the port configuration, command termination, and receiver wiring against the DL06 and indexer documentation. Test each device or link separately where the equipment supports it.
The successful field correction was card removal plus the normal PLC wiring. This is a temporary production restore if the application still requires the interface card for monitoring or another function. Do not reconnect it in parallel to the active transmit path until its port behavior and intended topology have been established.
Keep ASCII and byte-order checks behind the physical-layer test
Once the indexers respond with the card removed, preserve that known-good wiring and test the PLC message separately. Compare the PLC’s transmitted characters with a command the indexer accepts, including the exact command terminator and any required prefix. Use the indexer’s command documentation to determine those characters; do not add a control code merely because it is common on another device.
Byte swapping is relevant when the PLC converts numeric values into bytes or words for transmission. It is not a general remedy for ASCII visibility or line contention. Check the DL06 print instruction documentation and the actual memory layout used by the program before changing byte order. If a command consists only of literal ASCII characters, first confirm that the instruction outputs the intended character sequence; changing a numeric word’s byte order may not address the physical fault.
The original troubleshooting effort involved experimenting with appended characters, port configurations, and byte swaps, including swaps associated with PRINTV and VPRINT. Those experiments did not restore indexer response. After the network correction, change the program only if a controlled comparison shows that the transmitted message still differs from the command format the indexer requires.
Verify repeatable motion commands without the monitor in the path
Run verification with the production network arrangement, not only with a laptop attached. Confirm that the interface card remains out of the path if it recreates the failure, and send a low-risk command appropriate to the machine state before resuming normal motion.
- Confirm that each indexer receives and acknowledges or executes the intended command using its documented indication or status method.
- Repeat the command several times and confirm consistent behavior across both indexers, rather than relying on one successful transmission.
- Check that the same known-good wiring remains in place after reconnecting other equipment that is not part of the required PLC-to-indexer path.
- If the laptop is needed for diagnostics, attach it through an approved monitoring arrangement that does not drive or hold the active transmit pair. Verify that the monitor’s connection leaves indexer response unchanged.
If response disappears when the interface card returns, remove it again and retain the working direct arrangement while the card is evaluated. Do not accept a HyperTerminal display alone as proof of production communication.
Repair the network design before returning the interface card
A successful bypass restores operation; it does not explain whether the interface card is faulty, misconfigured for the topology, or unsuitable for its position on the shared path. Compare the card’s documented transmit-enable behavior, electrical connections, and intended network use with the actual PLC and indexer arrangement. The reported observation was that the card held the transmit line high; confirm the line state or card behavior with proper diagnostic equipment and the manufacturer’s instructions before assigning a permanent root cause to a component defect.
For permanent repair, choose a documented topology that lets the PLC drive the indexer receive path without contention and gives the laptop a separate or approved monitoring connection. If the design requires the interface card, confirm its required wiring and whether its output can be disabled or isolated when it is not transmitting. Do not invent a resistor, termination, adapter, or pinout as a workaround; use the actual port specifications and wiring diagrams for these devices.
If the card’s output state cannot be established safely, or the documented wiring does not match the field terminals, stop commissioning and contact official AutomationDirect support for the DL06/interface-card side and the indexer manufacturer for its serial port. Provide the exact models, wiring diagram, port settings, and the result of the card-removed test.
FAQ
How do I fix a DL06 that sends ASCII but the stepper indexer ignores it?
First isolate the physical path: remove the 422/232 interface card from the PLC-to-indexer network and test with the documented PLC wiring that worked for the indexers. Change ASCII formatting only after the indexers respond over that path.
How do I tell whether RS-422 wiring or ASCII formatting is the problem?
Use one known command and keep the program unchanged while testing the PLC-to-indexer path without the interface card. If the indexers then respond, the path or card was the problem; if not, compare the command termination, port settings, and pair wiring with the device manuals.
Why can HyperTerminal display DL06 output when the indexer does not respond?
The laptop’s receiver can observe characters without proving that the indexer has a usable signal path. In this installation, the laptop monitor and indexers required different wiring arrangements, and the interface card held the transmit line high.
Should I byte-swap DL06 PRINTV or VPRINT data?
Only if the PLC’s numeric-to-byte layout requires it and the transmitted message confirms a byte-order mismatch. Byte swapping did not correct the line problem here; verify the physical path before changing PRINTV or VPRINT handling.
Stop if the transmit line remains held, terminal definitions conflict, or safe isolation cannot be confirmed. Contact official AutomationDirect support and the indexer manufacturer before reconnecting the interface card or returning the machine to service.