Siemens 840D-SL file access can fail while ping continues to work because the tests exercise different layers of the network. Ping proves that an IP packet can travel between two addresses and return. A Windows share or FTP connection also requires the correct logical-drive definition, an active server service, accepted credentials, endpoint-security permission, and a stable physical link. Diagnose those layers in order.
Network-layer mechanism
The term reachability here means successful IP communication, not successful file access. A reply from 192.168.2.95 confirms the controller address is reachable at that instant. It does not prove that the Windows file-sharing or FTP service accepts a session from that device.
The installation had a Windows 7 Professional 64-bit PC, a Telekom SpeedPort 921V, and a 192.168.2.0/24 network. The router used 192.168.2.1, its DHCP pool covered 192.168.2.100 through 192.168.2.199, and the 840D-SL used the static address 192.168.2.95/24 with gateway 192.168.2.1. That static address sat outside the stated DHCP pool, so an ordinary DHCP lease collision was not the primary fault.
| Observation | Meaning | Next check |
|---|---|---|
| Ping succeeds, but neither a Windows share nor FTP opens | Basic IP reachability exists; application configuration, filtering, or link quality remains unproven | Check the logical-drive type and capture the connection attempt |
| No packet from the 840D-SL reaches the PC during an access attempt | The controller may not be initiating the expected session, the capture may watch the wrong interface, or the path may fail before the PC | Validate the drive definition, capture interface, filter, and physical route |
| The share works intermittently after the PC trusts the controller | The endpoint policy was one fault, but another intermittent fault remains | Inspect the cable and connectors, especially while the machine runs a cycle |
| Failures correlate with machine operation | Movement, vibration, cabinet conditions, or a marginal connector can disturb the link | Inspect and test the connection at X130
|
Check 1 — Address and ICMP reachability
Check 1: read the controller address, subnet mask, gateway, DHCP state, and PC address. Expect both endpoints to have unique addresses in 192.168.2.0/24. For the recorded configuration, 192.168.2.95/24 and a gateway of 192.168.2.1 are internally coherent. The displayed manual mode with DHCP off represents fixed addressing; it is not, by itself, a file-access fault.
Confirm that no other device answers for 192.168.2.95. A duplicate address can produce alternating reachability as switches and hosts relearn address mappings. Test from the PC while the 840D-SL is connected, disconnect the controller under an authorized maintenance condition, and repeat. A reply that remains after disconnection indicates an address conflict.
Check 2: ping in both directions where the equipment interface permits it. Expect stable replies rather than a single successful response. Record loss while the machine is idle and while it executes the operation associated with file-access failures. A clean ping is only a branch condition: proceed to the application checks. Loss or changing replies direct the diagnosis to duplicate addressing, switching, cabling, or connectors before changing share settings.
Check 2 — Logical-drive type and share path
Check 3: match the logical-drive type to the server actually being used. Select the Windows-network option identified as NW Windows when the destination is a Windows share. Select FTP only when an FTP server is configured, running, reachable, and supplied with the corresponding FTP path and credentials. Changing between these types without matching the server tests two different services and does not isolate a controller fault.
A Windows share path must identify the share, not merely the host. An entry containing only an address such as \\192.168.2.x names a computer but does not name the exported resource. Enter the complete UNC-style path in the logical-drive configuration, using the actual PC address or host name followed by the configured share name.
Check 4: verify the account locally on the Windows PC. Expect the configured user name to exist on that PC, the entered password to match, and that account to have both share-level and file-system permission for the target directory. Test with a file operation under the same account, not merely by browsing the share from a phone or another workstation. Success from another device proves that the server responds to that device; it does not prove that the 840D-SL identity or source address is allowed.
The HMI Embedded Network Manager was used successfully with the Windows-network option in related 840D installations. Treat its presence as part of the connection configuration, not as proof that the selected logical drive has the correct type, path, or credentials.
Check 3 — Outbound session capture
Check 5: capture traffic on the Windows PC while commanding one deliberate logical-drive access. Use a host filter for the controller address 192.168.2.95, but first select the PC interface carrying the machine network. Expect an outbound exchange from the controller followed by a response from the PC.
If packets arrive and the PC immediately rejects or resets the session, inspect the server service, authentication, share permissions, and endpoint-security logs. If packets arrive but the exchange stops without a useful application response, compare the timestamps with filtering events and physical-link indications.
If no packet appears, remove an overly narrow display filter and verify capture operation with a known ping. A visible ping proves that the capture interface and host filter can observe this controller. Then command file access again. Ping visible but no file-session attempt directs the next check back to the logical-drive type, path, saved configuration, and activation state.
The required restart behavior after changing a logical drive was not established for this installation. Apply and save the settings through the HMI interface first. If a new access attempt still generates no traffic, consult the machine documentation for the activation procedure and perform any documented restart only within an authorized maintenance window. Do not use an undocumented reboot as a substitute for confirming whether the controller emitted a connection attempt.
Check 4 — Host security policy
Check 6: inspect every filtering layer on the PC, including the installed Norton 360 Online policy. Opening firewall rules or disabling the Windows firewall does not prove that a separate security suite permits the machine. In this installation, the security software continued to control access until the controller was assigned full trust.
Expect the endpoint-security log or device policy to identify 192.168.2.95 as allowed after the change. Retest the same logical drive immediately. Lowering Windows share encryption to 48-bit did not restore communication, and activating the Windows IIS FTP server did not isolate the problem because the controller still had to initiate and complete the selected service session.
After the trust change, the Windows share began working intermittently. That outcome is diagnostically important: it confirms that endpoint filtering was one fault, while the remaining on/off behavior points elsewhere. Do not stop after the first successful browse. Repeat accesses and observe the machine through an operating cycle.
Check 5 — Physical connection under machine load
Check 7: inspect the entire Ethernet path to the controller interface used for the company network. The service socket X127 was not available for this diagnosis, so work proceeded through the installed path. Inspection at X130 found a field-assembled cable with a damaged RJ45 retaining latch. Replacing the connectors restored stable operation.
A damaged latch can allow the plug to move enough to disturb one or more contacts while appearing connected. Short ICMP exchanges may succeed between disturbances, while a longer authenticated file transaction fails. The stronger clue is correlation: file access failed especially while the machine executed a cycle.
Expect the plug to seat fully, latch positively, and remain immobile under normal cabinet vibration and cable loading. Inspect conductor termination, strain relief, bend radius near the plug, and any tension transferred from the cable bundle. Where plant procedures permit, monitor link indication and packet loss while gently stabilizing—not disturbing—the connector. A behavioral change identifies a mechanical fault that configuration changes cannot correct.
Resolving procedure and final verification
- Record the current PC and controller settings. Confirm the 840D-SL remains at
192.168.2.95/24, uses gateway192.168.2.1, and does not overlap the DHCP range192.168.2.100–192.168.2.199. - Configure the logical drive as
NW Windowsfor a Windows share. Enter a complete host-and-share path and the credentials of a local Windows account that has permission to the directory. - Apply and save the HMI configuration. Trigger one access while capturing traffic for host
192.168.2.95. - If the request reaches the PC but is blocked, authorize the controller in every active endpoint-security layer. For the recorded PC, this required assigning full trust in Norton 360 Online.
- Retest repeatedly. If access alternates between success and failure or degrades during a machine cycle, inspect the connection at
X130and the installed cable path. Replace damaged or unreliable RJ45 terminations using the site-approved method. - Verification check 1: expect stable ping replies from
192.168.2.95while the machine is idle and while it runs a cycle. - Verification check 2: expect the packet capture to show each commanded file-access attempt leaving the controller and receiving a response from the PC.
- Verification check 3: expect the mapped Windows drive to open repeatedly with the configured account and complete representative read and write operations permitted by the production workflow.
- Verification check 4: expect the share to remain available throughout a complete machine cycle, with no intermittent drive-access message and no link interruption at
X130.
Frequently asked questions
What happens if the Siemens 840D-SL pings but cannot open a Windows share?
IP reachability is working, but the file-session layer is not. Check the NW Windows drive type, complete share path, local Windows credentials, endpoint-security policy, and the physical connection at X130.
What happens if no 840D-SL file traffic appears in the packet capture?
First confirm the capture sees a ping from 192.168.2.95. If ping is visible but no file attempt appears, check the logical-drive definition, saved configuration, selected capture filter, and documented activation procedure.
What happens if the share works only after granting full trust?
The endpoint-security policy was blocking the controller even though other clients could browse the share. Continue testing because intermittent access after that change indicates a second fault, such as an unreliable RJ45 termination.
What happens if file access fails only while the machine runs?
Inspect the installed Ethernet connection for movement-sensitive faults. After repairing the damaged RJ45 termination at X130, expect repeated read and write tests to complete through a full machine cycle without a link interruption.