A passing transmit test and an alarm-history entry cover two different hops, so the missing file usually means the event action's source file or remote path differs from what the test exercised. Refresh the directory view first, read the action's source, destination and remote folder against the tested address-book entry, then confirm the file on the server by timestamp and size.
A transmit test that passes and an alarm-history entry that fires, with still no file on the server, means the two checks covered different halves of the path. The transmit test exercises the address-book entry, and the history entry records that the trigger fired. The failing hop is the event action's own source file, destination or remote folder. Work three checks in order: refresh the directory view you are judging the upload by, read the event action's source and remote path against the tested address-book entry, then confirm the file on the server by timestamp and size. The same three-hop order, trigger, action, transfer, is the one that sorts shop-floor screens and andon-style boards on the floor, and it holds here. Most cases end at the action's destination line, one edit from working.
Why does a passing transmit test still leave no file on the server?
The transmit test fires the address-book entry you selected and nothing else, so a green result clears the destination server, its credentials and its folder, and the fault sits in the event action's own source, destination or timing.
The test walks the test button's path. The event action walks the event manager's path: the tag condition goes true, the event manager runs the action, the action selects the file to send, and the FTP transaction writes it to the remote folder. A pass on the first path does not prove the second path ran. So keep the green result and move the search to the action. Open the event manager, find the action bound to your tag, and read which file it names and which address-book entry it sends through. If both read correctly, the next suspect is where the file lands, because a transfer that works can still write to a folder you are not browsing.
What does each symptom point to?
Match what you see to one hop before you edit anything: a history entry with no file points at the action's source or remote path, a stalled listing points at the data channel, and a rejected login points at credentials.
- The transmit test passes and the event upload never appears. The tested entry is healthy. The event action's source file or destination entry differs from what the test exercised, so read the action line against the tested entry (next sections).
- The tag fires in the alarm history and no file shows anywhere. The trigger ran, so trace the source: does the trend export exist, under the name the action expects, at the moment the trigger fires?
- No alarm-history entry appears at all. Either the trigger condition never became true or event recording is switched off; check the tag's condition and the panel's event logging before touching the network.
- The login works but the directory listing looks empty or lags. Refresh the view first; a desktop browser holds old listings. If the listing itself stalls, the data channel is the suspect.
- The server log shows a rejected login or a refused write. That is credentials or permissions, not routing: check the account and the write permission on the target folder.
- The panel raises a message such as "A folder or file doesn't exist" or "Failed to create the export file". Panel help files list these under the event manager's GUI errors. The source side failed before any transfer opened: the folder or file the action names was missing at send time.
Is the file really missing or is the directory view stale?
Refresh before you change a single setting: a desktop file browser such as Windows Explorer can hold an old directory listing, so reconnect and open the target folder again, and give a freshly fired event about 60 seconds to land before you call the file missing.
Check the same folder from a second client too: a command-line FTP session shows the directory as the server holds it, without the first client's cache. If the second client sees the file, the transfer worked and only the view was old. If the login succeeds and the listing itself stalls or times out on both clients, the fault is the FTP data channel, and the article on FTP login works but the directory listing fails walks that repair. Judge absence only from a refreshed listing plus the server's own log: a connection and a write at the trigger time mean the file exists, so the question becomes which folder it went to.
What does the alarm-history entry actually prove?
The entry proves one fact: the trigger condition became true at that recorded timestamp, so take a fired entry at 06:00:03 and anchor every later check to 06:00:03, from the server's log window to the file's modified time.
It records the event, and it does not confirm the transfer completed. Two follow-ups make the entry useful. First, expect entries only when the panel records events; that is the same rule that leaves an alarm history empty at download when logging was switched off, covered in why an HMI alarm history downloads only if logging was on. Second, watch the action as well as the trigger: confirming the send itself from the event browser is the same discipline engineers apply when confirming email sends from an alarm and event browser. If the entry exists and the trigger repeats on schedule, the event half of the path is cleared, and every remaining check belongs to the transfer half.
What should the event action point at?
Open the event manager and read the action as three lines: which source file or trend export it names, which address-book entry it sends through, and which remote folder it writes to, then hold all three against the entry your transmit test passed.
Hunt three mismatches in that order. Source: the action must name the export your trend produces, and that file must exist when the trigger fires; an export-file error at send time means the source never existed. Destination entry: compare the server address, the username and password and the account type against the tested entry; if you edit the tested entry to match the action, run the transmit test again, because the old pass described the old settings. Remote folder: the test may drop its file into the folder you browsed while the action writes a different directory string, so browse both folders before you edit anything. If the server accepts anonymous access, the username it expects is anonymous or ftp, set according to the server's own configuration.
What should a 16-pen example produce from trigger to file?
Take a 16-pen trend sampling once per second over a 60-second window: the export should hold about 960 sample rows, the upload should start within seconds of the trigger, and the file on the server should carry a modified time from that same minute.
The rate and the window are example inputs; set both from your own project. The arithmetic: 60 samples per pen across the window, times 16 pens, is 960 samples, and one row per sample gives roughly 960 rows plus any header line. Scenario: the trigger fires at 06:00:00 and the history entry lands at 06:00:01. A healthy path leaves a new file in the action's remote folder, with a modified time a second or two after 06:00:00 on the server clock and a size consistent with about 960 rows. Read the fault from the outcome. A file present but tiny means the export ran short, so the source is wrong or empty. The folder holds the test file but no event file, so the action writes elsewhere: correct the action's remote folder. A refreshed listing with nothing new and no connection in the server log at 06:00:01 means the action never ran, so go back to the event manager line.
How do you test the fix without touching the running line?
Book a controlled trigger in an approved window, fire one event, and read three observations together: the new history entry, a refreshed server listing, and the file's timestamp and row count, then repeat the normal trigger for at least two full cycles.
Save a copy of the working project before the first edit and change one setting at a time, so the change that works is the change you record. Two cycles matter, because a condition that fires once can pass the first test and fail the next. The discipline is the same one behind a red offline link indicator that appears while a TCP port test passes: each check certifies its own hop, and the article on the red offline link indicator when the TCP port test passes shows how the hops separate.
Recommendation: Refresh the directory view first, then read the event action's source, destination entry and remote folder against the address-book entry the transmit test passed, and confirm the file on the server by timestamp and size. Edit the event action or its path when those checks disagree with the history entry, and leave the address book, the switch settings and the server alone while the test passes and the server log stays clean.
When do you stop and hand the fault to support?
Stop when a controlled trigger still produces no file after the source, destination and remote folder verify clean, when the server log shows a rejection you cannot clear, or when the action's configuration reads correct and stays silent; preserve the project and the logs and escalate.
While the ticket is open, pull the trend data by a method that already works in your plant and treat that as a workaround, not the repair. Record each change with its time, so the vendor sees one variable at a time. Once the event path passes a controlled trigger, keep the feed useful: the article on collecting HMI trend logs over FTP into a database shows how the files land in one queryable place.
Questions
Does the transmit test send the real trend file?
The button's job is the address-book entry: server address, credentials and folder. A pass tells you that entry is reachable. The trigger condition, the event manager and the action's file selection sit outside that job, which is why the file can still be missing after a clean result.
Why does the alarm history show the tag but the server log shows no connection?
Line the two clocks up first: a panel clock running minutes behind the server makes an upload look absent in the log window you are reading. If the windows truly overlap and the server log still shows no connection, the action failed before any transfer opened, so check its source file selection and its destination entry first and leave the network settings alone.
What should I send when I escalate to the panel vendor?
Send the panel model and its software or project version, the event manager configuration with the action's source and destination lines, the transmit-test result and the time you ran it, the alarm-history entries around a fired trigger, and the server's FTP log lines for the same window. Screenshots of the action line and the address-book entry shorten the exchange.
How long should I wait between the trigger and the check?
Refresh the listing at about 60 seconds after the trigger. If the server log shows no connection attempt 5 minutes later, the transfer never started, and waiting longer will not change that; move back to the event manager and the action's source and destination lines.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.