Introduction
During on-site commissioning, engineers frequently encounter software crashes, often leaving them at a loss with no clear resolution. Previously, I published an article titled “INTOUCH Crash Troubleshooting and Resolution Guide,” which addressed initial steps. This article serves as an advanced continuation, offering a broader scope and focusing on a structured troubleshooting methodology.
2. Software Troubleshooting Steps
2.1 Reboot the Computer
In any IC project, troubleshooting hardware or software issues must begin with a reboot. Only when rebooting fails should deeper investigation commence. Never overlook this step—sometimes the effort of extensive troubleshooting pales in comparison to a simple power cycle.
2.2 Locate and Configure Software Log Settings
Each software package has unique settings for exporting log files, defining the scope of logged data. This step involves enabling the log recording switch—a critical key to unlocking diagnostic insights.
- Example: Architect Multiplexer Software
- logLevel=5 => Enables logging of library traces, traces, information, warnings, and errors.
2.3 Collect Windows Logs
For crash incidents, the standard procedure is to gather Windows logs first.
- Press Win + R, type eventvwr.exe, and press Enter to open the Event Viewer.
- Save the Application and System logs for subsequent analysis.
2.4 DMP File Dump
DMP files can sometimes reveal underlying issues.
2.4.1 Manual Dump
2.4.2 Automatic Dump
- These posts should be reviewed together. In Windows, the Windows Error Reporting (WER) system can be configured to generate dumps upon application crashes:
(1) Open regedit.exe.
(2) Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.
(3) Create a DumpFolder key of type REG_EXPAND_SZ to specify the directory for storing dump files.
(4) Optionally, create a DumpCount key of type REG_DWORD to set the maximum number of dumps.
With this configuration, an abnormal program exit will generate a dump file in %LOCALAPPDATA%\CrashDumps, as illustrated below.
2.5 Log Comparison and Analysis
With software logs, Windows logs, and DMP files in hand, a comprehensive analysis can typically be conducted to identify the root cause.
3. Hardware Troubleshooting Steps
If software logs fail to pinpoint the issue, the challenging task of isolating hardware variables begins. The network topology for this project resembles a star configuration—slightly complex but reasonably clear.
3.1 Verify Configuration and Network Stability
Software configuration involves parameters such as IP addresses, COM port settings, baud rates, parity, and polling addresses. If a functional system exists on-site, assume the software is sound and meticulously compare settings to identify potential misconfigurations.
- Check Network Stability: Use the CMD command ping 192.168.*.* -t >> D:\log.txt (as introduced previously) to automatically export ping logs for analysis.
3.2 Replace the Computer
If crashes persist, the issue may lie with the computer. Test with a different machine to isolate the problem.
3.3 Bypass Intermediate Nodes
If intermediate nodes, such as managed switches, are involved, bypass them and connect directly to the PLC communication card to eliminate potential interference.
3.4 PLC Diagnostics
To determine if the PLC is at fault, revert to the initial software troubleshooting step: perform a power cycle and reseat both the CPU and communication card.
3.5 Single-Variable Device Replacement
Replace components one at a time in a bottom-up sequence: communication card, CPU, then I/O card. This step demands patience—proceed with one change, wait, and test (checking for crashes) before the next. In projects with redundant communication cards and CPUs, avoid replacing all at once to prevent overlooking critical issues. Perform replacements in stages, and if rushed, calmly explain the need for a “slowly” approach. Resilience under pressure is essential for IC engineers.
4. Conclusion
This software crash troubleshooting case required me to progress through Step 3.5, marking it as one of the most challenging diagnostics I’ve encountered. I encourage the community to share experiences and collaborate on refining these techniques.