A DL250 port 2 can transmit a DirectNet request without replying when the serial byte stream, target station, port configuration, or physical link is wrong. The Palm M100 setup described here sent an initiate sequence shown as 4E2205; port 1 later acknowledged a request, while port 2 did not, even after its station number was changed from 2 to 1.
Compare the transmitted bytes with the DirectNet request
Do not keep switching between “ASCII” and “HEX” without checking what the Palm actually places on the wire. Those descriptions can refer to different things: a hex display may represent binary bytes, while ASCII mode may send the characters that spell the hex digits.
| What the Palm sends | What appears on the serial line | What to check |
|---|---|---|
Hex bytes 4E 22 05
|
Three byte values | Confirm the DirectNet manual calls for those bytes in that position. |
ASCII characters 4E2205
|
Six character bytes | Confirm the protocol expects literal ASCII digits rather than binary values. |
The reported sequence is labeled as hexadecimal, but that label alone does not prove which representation the Palm transmitted. Use a serial capture or a diagnostic tool that displays both raw byte values and printable characters. Compare the full request against the DirectNet documentation for the DL250, including any required address, command, length, termination, or check fields. Do not add or remove framing bytes by guesswork.
If the captured request differs from the documented format, correct the Palm output first and retest. If the complete request matches, continue to the station and port checks.
Read the port 2 station setting and match the target
Read the station number configured for port 2 in DirectSOFT and record it. The original setup used station 2; a later test changed the port 2 station to 1. The reported DirectNet manual states that station numbers from 1 through 90 designate a port as a slave. Both 1 and 2 fall within that stated range, so changing 2 to 1 is not, by itself, proof that the port will respond.
- Read the current port 2 station number in the PLC configuration and confirm the setting was written to the intended port.
- Check the Palm request’s destination station field in the complete documented frame. Make it match the port 2 station number.
- Confirm port 2 is configured for the required DirectNet role and serial settings. Read the relevant port configuration and DirectNet manual; do not copy port 1 settings unless the hardware and application documentation calls for them.
- Retest with one documented request, then record the PLC response and any diagnostic indication.
Port 1 is described as always being a slave in the reported setup, but that does not establish the role or protocol configuration of port 2. Treat each port as a separate interface until its configuration confirms otherwise. If the station matches and port 2 is configured for DirectNet, move to the wiring and signaling checks.
Trace the transmit, receive, ground, and handshake paths
The Palm-to-DL250 wiring was reported as follows. Verify each connection at both connector ends rather than relying on cable labels; a crossed transmit/receive pair or a handshake line held inactive can prevent an otherwise valid exchange.
| DL250 port 2 pin | Signal named in setup | Palm M100 pin | Signal named in setup |
|---|---|---|---|
| 2 | Transmit | 3 | Receive |
| 3 | Receive | 5 | Transmit |
| 7 | Ground | 10 | Ground |
| 4 | Ready to send | 6 | Clear to send |
| 5 | Clear to send | 4 | Ready to send |
Confirm the connector pin numbering and signal definitions from the applicable DL250 port and Palm interface documentation. The pin list records the wiring used; it does not establish that the cable pinout is correct for the exact interface hardware. In particular, verify the crossed ready-to-send/clear-to-send lines and determine whether the configured port and Palm require hardware handshaking. If they do not, use only the documented handshake configuration or cable arrangement.
Measure or capture activity in both directions during a request. If the Palm transmits but no electrical response appears from the PLC, continue with port configuration and a controlled peer test. If the PLC transmits but the Palm shows nothing, inspect the receive path and the Palm’s serial settings.
Use the working port 1 test to isolate the failure
Port 1 eventually acknowledged a DirectNet request, while port 2 did not. This is a useful comparison, not proof that both ports share the same configuration or wiring. Use the same documented request and the same Palm serial settings to compare the paths, changing one connection at a time.
| Observation | Likely area to inspect next |
|---|---|
| Port 1 responds; port 2 does not with the same Palm and request | Port 2 station, protocol/role configuration, connector pinout, or port-specific settings. |
| Neither port responds to a captured, documented request | Palm byte framing, target address, serial configuration, or shared cable/interface path. |
| PLC response is visible electrically but not on the Palm | Palm receive wiring, receive settings, and handshake behavior. |
| No request appears at the PLC connector | Palm transmit configuration, cable continuity, or connector pin numbering. |
Do not infer that port 2 needs slave RLL solely because it is silent. The reported technical guidance was that the PLC should acknowledge DirectNet requests automatically without slave RLL instructions. Test the configured port and valid request path before adding ladder logic that may not address the cause.
Restore communication with a controlled test sequence
Once the request format, station match, port mode, and electrical path are verified, restore the link with a known-good documented request. Change one variable per test and preserve the working port 1 configuration as a comparison, not as an assumed template.
- Record the present port 2 configuration and station number before making changes.
- Set the port 2 station to a documented slave value in the stated range of 1 through 90, then set the Palm target to that same station.
- Configure the Palm output to match the exact documented DirectNet frame representation—binary bytes or literal ASCII characters—and required framing.
- Connect the documented transmit, receive, common, and handshake signals. Confirm actual connector pin numbers against both device manuals.
- Send one request and capture the transmitted bytes and PLC response. If the request is correct but port 2 remains silent, repeat the same test through port 1 only if the approved wiring and procedure permit it.
This sequence restores service only when the request reaches a correctly configured port and receives a reply. Do not leave experimental framing, undocumented wiring, or a station number that conflicts with the Palm target in production.
Verify the reply before returning the connection to use
Confirm the Palm sees a valid DirectNet response—not just transmit activity—and that the response corresponds to the request and intended station. Capture the request and reply once the link works so the byte representation, station, and port configuration can be repeated after a cable or Palm change.
- Verify port 2’s configured station matches the request destination.
- Verify the serial capture matches the documented request and response framing.
- Verify the PLC response is present at the receiving interface and is displayed correctly by the Palm.
- Record the final port settings and cable pinout; remove temporary test changes.
If a valid documented request still produces no response on port 2 after its configuration and wiring are verified, stop changing settings and escalate with the port configuration, captured bytes, pinout, and test results to official AutomationDirect technical support.
DirectNet DL250 port 2 FAQs
How do I tell whether the Palm sends ASCII or hex bytes?
Capture the serial output. Hex 4E 22 05 is three byte values; ASCII 4E2205 is six character bytes. Compare the capture with the DirectNet frame definition.
How do I set the DL250 port 2 station number?
Read and configure port 2 in DirectSOFT, then make the Palm request’s destination match. The reported manual gives 1 through 90 as the slave station range.
Does port 2 need slave RLL to acknowledge DirectNet?
The reported guidance was that the PLC automatically acknowledges DirectNet requests without slave RLL. Verify the port’s DirectNet configuration and valid request before adding ladder logic.
How do I test whether the port 2 cable is wired correctly?
Check connector pin numbering and continuity against both device manuals. Verify transmit-to-receive, common ground, and the ready-to-send/clear-to-send paths listed in the wiring table.
When should I stop troubleshooting DL250 DirectNet?
Stop if the documented pinout or interface compatibility is unclear, or if port 2 remains silent with a captured valid request and verified configuration. Send official AutomationDirect support the port settings, request/response capture, and cable pinout.