SNP-X major error 15, minor error 4 means the PLC's SNP-X slave never answered the master's Attach message, so the master dropped the link. Capture the exact alarm pair, verify the serial path and the documented port settings at both ends, then soak-test a 40-tag set before blaming the 400-tag database.
Your HMI connects, pulls a round of tags, then dies with an alarm reading SNP-X major error 15, minor error 4, and changing the baud rate and the receive timeout has done nothing. That pair has a printed meaning: the SNP-X slave task inside the PLC never answered an Attach message, so the master gave up and dropped the link. The timing in front of you is the useful part. A link that connects in about 1 second and passes real data worked once, so you are chasing an exchange that failed on a repeat, not a dead cable or a wrong protocol. Here is the order that finds it: capture the pair, walk the wire, match the settings, then settle the tag count with a soak test.
What does SNP-X error 15 minor 4 mean?
SNP-X major error 15, minor error 4 means the SNP-X slave inside the PLC never answered the master's Attach message, so the master raised the alarm and dropped the link; the printed fault location is the slave task, so start on the serial path.
The PLC manual splits the pair in two. Major error 15 is the family: an error occurred within the SNP-X task in the remote slave device. Minor error 4 is the row that matters here: the SNP slave did not respond to the Attach message from the master. SNP-X driver manuals for other panels print the same row, some as code 04h, so the meaning holds whichever HMI software sits on the master side.
An Attach is the handshake that opens every new SNP-X communication. The master sends an Attach, or a Long Attach COMMREQ, and no tag data moves until the slave answers. A missing answer kills the session before any data question starts, which is why the alarm names the handshake and never a tag.
Read the major and minor values off a fresh alarm and write them down; 15/4 is the shorthand used below. Alarm pairs get transcribed wrong between shifts, and a pair that is actually 14 with 4 sends this diagnosis down the wrong table row.
Why does the HMI connect, update tags, then disconnect a second later?
Because the first Attach succeeded: a link that connects in 1 second and passes a round of tag updates has demonstrated that the cable, the port settings and the slave all work at least once, so you are hunting an intermittent failure, not a dead line.
| What you see | What it points to | Next check |
|---|---|---|
| Connects in about 1 s, tags update once, then the 15/4 alarm and a disconnect | One Attach succeeded, a later one went unanswered | Walk the physical path, then check what else is on the port |
| The alarm survives a new cable, a second PC and a different Windows edition | The workstation is out as a suspect | Match every setting at both ends, then run the load test |
| The attach holds, the link stays up, but timeouts or checksum errors appear while polling | A working link with a data problem | The timeout and checksum article, not this page |
Three causes produce a handshake that worked once and failed on a repeat, and each carries a test that tells it apart.
The reply was lost or corrupted on the wire. A loose connector shell, a damaged conductor or a serial run draped across a motor power cable passes short bursts and fails the next exchange. Reseat the connectors and swap in a known-good cable; if the survival time moves, the wire was the cause.
Something else was on the port. A programming laptop, a logger or a second master left wired to the CPU. Run one connect cycle with everything else unplugged and see whether the drop disappears; the article on a SCADA connection to a PLC when an HMI panel holds the port walks that case in detail.
The reply was too late for the receive window. You have usually tested this one already, because changing the receive timeout changed nothing, and that is evidence the reply is not merely late.
Reproduce the alarm once on a second PC with a different Windows edition before spending an hour on the workstation. If the alarm follows the cable, the PC leaves the suspect list.
What should you check on the physical serial path first?
Check the whole path before touching a single setting: the connector on the exact CPU port, every adapter and splice, and the cable run, because a link that survives 1 second and dies on the next Attach is the classic signature of a loose shell or a damaged conductor.
Tell whoever owns the running process before you pull a connector, because the HMI picture disappears the moment the link comes out. Then work the path in this order.
- Confirm which physical port the cable reaches. A CPU carries more than one serial port and they do not all run the same protocol, so the driver must point at the one that is wired.
- Reseat every connector in the path, including gender adapters and terminal blocks, and look for a loose shell, a bent pin or a splice hanging on screw terminals.
- Simplify. Remove every adapter the link does not need and run one known-good cable that meets the documented requirements for the port, wired the way the PLC documentation shows. Never rebuild a serial cable from the alarm text.
- Reroute. A serial run laid beside a motor power cable collects noise that corrupts exactly the fast exchanges.
If the com LED never blinks at all, start one step earlier with the article on an HMI to PLC serial timeout with a dead com light; this page is for a link that talks and then stops.
Which port settings must match at both ends?
Every parameter the two manuals list: protocol selection to SNP-X on the CPU port, baud, parity and stop bits, plus the slave address in the driver, and each value comes from the PLC port's own documentation, not from a guess or the alarm text.
Line them up end against end. The port's protocol switch set to SNP-X, the way driver manuals for the protocol ask you to do it from the PLC's programming console. The port's physical interface set to the electrical standard its documentation requires, RS-232C or RS-485. Baud, parity and stop bits identical on both ends. The slave address the driver dials matching the CPU's own station setting.
If every value matches its manual, the settings question is closed and you can stop touching it. If one value differs, change that one, rerun the connect, and write down the before and after so a fix cannot get lost.
Does a 400-tag database cause error 15 minor 4?
Not first: the documented meaning of minor 4 is an unanswered Attach, and tags move only after an Attach succeeds, so you settle the attach exchange before testing load; a one-tenth set of 40 tags clears the suspicion in one 15-minute test.
The order follows from the alarm itself. Minor 4 is printed against the Attach, and the Attach precedes every data read, so the path and the settings come before the database. The tag count still earns its own test, because it is the one variable you can change from the driver side in five minutes, and a database of 400 tags keeps the link busy enough to matter once the handshake itself is sound. The next section runs that test with the arithmetic shown.
Example: a 400-tag HMI drops 2 seconds after connect, so what does the step test show?
Cut the database from 400 tags to 40, soak the link for 15 minutes, and let the survival time decide: a drop that still lands at about 2 seconds clears the tag count, while a link that holds 900 seconds sends you up the ladder in blocks of 100.
The situation in front of you: 400 tags configured, a connect that lands in about 1 second, one round of updates, then the 15/4 alarm at the 2-second mark, with baud and receive timeout already tried and a second PC reproducing the drop.
Run the step test. Trim the driver's tag list to 40 tags, one tenth of 400, and start the clock. A 15-minute soak is 900 seconds, 450 times the 2-second life the link showed at full load. Two outcomes decide the afternoon.
The alarm still fires at about the 2-second mark. The link died before any meaningful polling volume moved, so the tag count is not the trigger. Close the load question and go back to the physical path and the settings table with the exact alarm pair in your notes.
The link holds all 900 seconds with zero 15/4 alarms. Load is now a live suspect, so climb back up in blocks of 100 tags: 140, 240, 340, 400, with one 15-minute soak at each step. Five runs at 15 minutes take 75 minutes of bench time for a verdict either way.
When the alarm returns in a block, the ceiling sits between the last good count and the failed one. A database of 240 tags that held while 340 dropped puts the working limit somewhere in that band, and the live database goes below the last good count. If the full 400 passes clean, the load question closes for good and the remaining suspicion goes back on the wire. If the tag count you actually need sits above the ceiling the test found, one serial link is carrying more than it should, and the article on multiple PCs polling one PLC shows how to split the traffic across two links.
When does changing baud or receive timeout actually help?
Only when evidence hands you a number: a verified mismatch between the two manuals, or a measured reply time that the receive window cuts short; with the path sound and both ends matched, more blind changes to baud and timeout add nothing, because the earlier attempts showed they change nothing.
A parameter change pays in exactly two situations. First, the settings pass turned up a value that disagrees with its own manual: fix that value, one end at a time, and rerun the connect before touching anything else. Second, the attach now holds and the failures have moved into the polling itself: timeouts, checksum errors or dropped messages on a link that stays up. That is a different disease with its own fixes, and the article on HMI PLC timeout and checksum errors picks it up there, as does the one on dropped PLC-triggered messages on a serial HMI panel.
Keep the failed attempts in the ticket. Two values were varied without moving the alarm, and that record stops the next engineer from starting in the same dead end.
What proves the link is stable again?
A soak, not a single reconnect: run the full database through one uninterrupted session well past the old 2-second failure point, target zero 15/4 alarms across a 15-minute bench soak and then a full production shift, and log every alarm pair that comes back.
Pass means the link reaches tag updates, holds the soak and finishes the shift with the alarm log clean. A recurrence gets logged with three facts beside it: the exact major and minor pair, the settings in force at both ends, and what the physical path looked like that day. If the alarm survives a sound path, matched settings and a 40-tag soak, the record plus the CPU's hardware and firmware revisions goes to the PLC vendor's support line, because the remaining suspect is the slave task in firmware.
Recommendation: Treat 15/4 as a failed handshake and work the fixed order: capture the exact pair on a fresh alarm, reseat and simplify the serial path, match every documented setting at both ends, then run the 40-tag soak for 15 minutes. Change baud or the receive timeout only when a verified mismatch or a measured reply time gives you the number to set. If the alarm survives a sound path, matched settings and 40 tags, stop turning knobs and take the pair, the settings and the CPU revisions to support.
Questions
What if the alarm shows major error 14 instead of 15?
Capture the pair again on a fresh alarm and use the number you see, not a note from an earlier incident. The attach-response diagnosis in this article is the printed entry for major 15 with minor 4, and major 15 belongs to the SNP-X slave error family, which points away from the HMI software. A different major value is a different row of the error table and earns its own diagnosis before you change a single setting.
Does this alarm mean the PLC or the HMI is damaged?
No. The alarm reports a handshake the slave never completed, not a hardware fault; finding and fixing it changes no logic and no data in the CPU. Plan the physical checks for a window when the process owner can watch the HMI go offline, because the picture disappears the instant a serial connector comes out.
What should you take to PLC support if the alarm survives every test?
Four things: the exact major and minor pair from a fresh alarm, the CPU's hardware and firmware revisions, the complete list of serial settings you verified at both ends, and the soak result: the tag counts you ran and how long each link lived. With a sound cable, matched settings and a 40-tag set still dropping, the evidence points inside the slave task, and that is where the vendor's documentation and support finish the job.
Can a longer receive timeout mask the drop?
It can hide one occurrence and cost you the diagnosis. If the slave's reply is merely late, a longer window turns a failed exchange into a slow success. If the reply is lost or corrupted on the wire, no window length helps, because nothing ever arrives to receive. Set the timeout only from the two manuals plus a measured reply time, and log the change so a mask cannot quietly become the new normal.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.