One fetcher outside the control network reads the weather feed every 15 minutes and writes a recipe CSV. It uploads the CSV to the HMI over FTP, so the screen never needs an internet route. The file carries the observation time, and the display flags any value older than 60 minutes.
You want the outside temperature, the humidity and a condition icon on a screen in the plant. You want the controller and the plant network to have nothing to do with the internet to get them. The setup that does both is a fetcher: a small computer outside the control network that reads the weather feed over HTTPS, writes a simple CSV file, and hands it to the screen across the plant LAN. The file carries the observation time, so the screen can show how old the reading is and flag a lagging feed openly. This page gives the parts list, the refresh numbers, the file format, a worked day of arithmetic, and the checks that tell you each handoff works. The defaults used throughout: a 15-minute fetch, a 5-minute screen-side load, a 60-minute staleness flag.
Why can't a PLC or HMI read a weather feed directly?
Because the feed is a web document in XML or JSON, a PLC has no documented way to fetch and parse it, the HMI has no reason to hold an internet route, and one fetcher outside the control network covers both for the price of one outbound connection.
Most controllers offer no supported way to request a web resource inside scan-cycle logic. Parsing a changing XML document there is a project with no manual behind it. Unless your controller's documentation names such a function, plan on no. The XML to Modbus gateway that comes up for this job deserves the same question before a purchase order. The phrase describes conversion between Modbus varieties on one network, so ask the vendor whether that device polls a web feed on its own, which schema it accepts, and which side of the Modbus conversation it takes. A converter between serial and Ethernet Modbus and a fetcher of web documents are different products.
The shortcut in the other direction, hosting one weather server at headquarters and letting every plant pull from it over a public Modbus TCP address, opens a public door on each plant network. One outbound connection would carry the same data just as well. If several sites genuinely must share one feed server, that is a server-exposure project with firewall, reverse proxy and authentication layers of its own, and a guide to exposing a plant dashboard server to the internet securely shows what that stack looks like.
What hardware does the setup need?
Three pieces: a fetcher computer, the screen, and one Ethernet drop from the fetcher into the plant switch. The plant side gains no new route to the internet, and the fetcher is the only device allowed outbound HTTPS.
- Fetcher. An embedded Linux board or any office PC that is already powered and allowed outbound HTTPS. The whole job is one script on a scheduler, so almost anything runs it.
- Screen, route A. An HMI panel with recipe import over FTP, a standard feature of many HMI packages. Its FTP server lives on the plant LAN and reads the file the fetcher writes.
- Screen, route B. A standalone signage display. Our panel-mount Android displays play image and video files from microSD or USB, with the player included and no subscription, so route B means the fetcher renders the values into a slide image and the card carries it.
- One Ethernet drop from the fetcher to the plant switch, and for route A an FTP account on the HMI.
How often should the fetcher pull the feed?
Set the fetch to 15 minutes and the screen-side load to 5 minutes. A healthy public weather feed publishes observations about every 5 minutes, so a 15-minute fetch never outruns the source and still puts a fresh value in front of operators within one load cycle.
The number that decides the fetch interval is the source's publishing cadence, which the feed's documentation states. Fetching faster than the source publishes buys no freshness and spends requests. Lag is the second number. The operator of one public weather API has documented observations arriving about 20 minutes late in ordinary operation and 1 to 3 hours late during recent service trouble, and that gap is what the age stamp later in this page is for. With a 15-minute fetch and a 5-minute load, a change outside reaches the screen in 20 minutes at worst, source lag aside. For a temperature line nobody acts on minute by minute, an hourly fetch would also serve; tighten the interval when operators use the number.
What does the fetcher do, step by step?
The fetcher fetches, parses, writes, uploads and logs, in that order. Every stage leaves a timestamp you can compare later; the build is six steps.
- Export one known-good recipe file. Create or export a recipe CSV from your own HMI project and keep it as the format reference. The CSV is the part this method breaks on, so the generated file has to match its header row, field order, delimiter, quoting and line endings exactly.
- Choose the fields. Outside temperature in °C, relative humidity in %, condition code, observation timestamp: four fields and a header. Leave the rest of the feed unread.
- Fetch and parse. Request the feed over HTTPS, pull those four values, and treat a missing or malformed field as a failed run that writes no file.
- Write and diff. Generate the CSV, then compare it with the reference file at the byte level. A stray control character or a line-ending mismatch is the usual reason a panel refuses a file that looks right in an editor; explicit newline handling, and on Windows a POSIX compatibility layer, is the usual cure.
- Upload. Place the file on the HMI's FTP server in the path its recipe function reads, and treat a failed transfer as a failed run.
- Schedule and bind. Put the script under cron on the fetch interval, set the HMI to load the recipe on the screen-side interval, and map a tag copy from the recipe fields into the PLC tags you want to carry.
Run the chain once on sample values you chose before pointing it at live data.
How does the screen show the values?
An HMI that loaded the recipe shows the four fields on whatever display objects you bind to them, and a standalone signage screen shows them inside a rendered slide image; pick the route by how current the number on screen must be.
Route A is the one for numbers people act on. Each recipe load refreshes the fields, and the tag copy that carries temperature into the PLC can feed another screen or a marquee at the same time. Route B renders the values plus the age line into a slide image that rides in on the card, the signage route from the parts list above. It suits a break-area or lobby notice where a slide written this morning is good enough, and it is the wrong tool for a reading operators check by the minute.
Where the line sits between this kind of notice screen and a real operator interface is its own question; the factory status display versus operator HMI comparison draws it, the choice of a live factory data display as signage or dashboard covers placement, and building a factory data table for an offline screen handles layout and column counts. If the content you want is a live web page instead of a file, showing a web OEE dashboard on a factory TV is the separate route that puts the screen itself on the network.
What does a worked example look like?
A machine shop wants outside temperature, humidity and a storm icon on the screen above the shipping door, refreshed every 15 minutes with a 60-minute staleness limit; here is one day of that setup in numbers.
- Fetch and load counts. 24 h × (60 ÷ 15) = 96 fetches per day. The screen side loads the recipe every 5 minutes: 12 loads per hour × 24 h = 288 loads, all inside the plant LAN.
- File size and traffic. Four fields plus a header run about 200 bytes per CSV, so uploads move 96 × 200 B = 19,200 B, about 19 KB per day. The outbound pulls are the same count against the weather service.
- Healthy morning. At 10:15 the fetcher reads an observation stamped 10:12 with 31 °C and 62% relative humidity. Age at display = 10:15 - 10:12 = 3 minutes, so the line reads "31 °C, 62%, observed 3 min ago" and the sunny icon stays.
- Lagging afternoon. At 14:35 the newest observation is stamped 13:05. Age = 14:35 - 13:05 = 90 minutes, which is 30 minutes past the 60-minute limit, so the stamp line switches to "observation 90 min old". The values stay on screen labeled as old, and the banner clears at the next good fetch.
- Failed run. The 11:30 fetch times out, so no file is written and the 11:35 load keeps the 11:05 values. Age keeps climbing from the observation time, so the screen states plainly that the number is old while the pipeline is down.
How do you keep a stale reading from fooling operators?
Put the observation timestamp in the CSV, compute the age on the display side, and let the age line take over when it passes 60 minutes; a value with no age next to it should never appear on the screen at all.
Compute the age from the observation time in the feed, never from the fetch time, because the two can differ by minutes or by hours. On a failed fetch, keep the last good file and keep counting the age up; a blank or a zero would read as data. Set the limit by the use. Sixty minutes works for a temperature line on a notice screen, a number tied to a shift decision deserves something tighter, and a value nobody acts on can carry a wider one. Size the age line for the distance operators actually stand at, using the small-screen text readability rules.
One boundary stays fixed: weather on a plant screen is display data. Keep an unvalidated web value out of anything that starts, stops or interlocks a machine. If a process genuinely needs weather as an input, engineer it like any other sensor, with limits, validation and a defined fail state.
How do you check the handoff works?
Check the four handoffs in order, fetch to file, file to server, server to recipe, recipe to screen. The first stage whose timestamp stops advancing is the one to fix; each check takes a few minutes.
- Run the script by hand. The log should print the fetch result, the four parsed values and the transfer result. Diff the written CSV against the exported reference file at the byte level.
- Send a test value through. Write 99 °C into a test CSV, upload it, trigger the recipe load, and follow the number onto the screen and into the PLC tag. A value you chose exercises the whole chain in one pass.
- Stop the fetcher. Leave it off for 70 minutes and check that the stamp crosses the 60-minute limit and the banner appears; start it again and check that the age falls back to minutes.
- Read the four timestamps. Script run, FTP completion, recipe load, observation time. When the values freeze, the newest timestamp that stopped moving names the failing stage.
Recommendation: Run the fetcher on a small Linux-based board or an existing office PC outside the control network, fetch every 15 minutes, load the recipe every 5 minutes, and stamp every value with its observation time and a 60-minute staleness banner. Use the HMI recipe route when operators act on the number and it must be minutes old; use the card-fed signage route for a notice slide where an update written that morning is good enough.
Questions
Can an XML to Modbus gateway fetch the weather feed on its own?
Treat the label as a data-conversion claim and ask the vendor three questions: does the device poll the web feed itself over TCP/IP, which XML or JSON schema does it accept, and does it sit on the plant side as the Modbus server or client. A gateway that converts between Modbus varieties on one network is a different product from one that retrieves web documents. Get the answers in writing before the purchase order; if the device cannot fetch, the external fetcher pattern on this page still applies.
Can the screen show weather icons instead of plain numbers?
Yes, and the condition code already in the CSV is the hook. Have the fetcher map each code the feed emits to a short name such as sunny, storm or night, and add that name as one more CSV field. On the HMI route the field can select between icon images or drive a text label; on the signage route the rendered slide carries the icon directly. Test the unknown-code case once so an unexpected code shows a neutral icon.
What about a remote site with no server room?
The fetcher needs one outbound HTTPS connection and nothing coming in the other way, which fits a remote site well. A small embedded Linux board next to the HMI, behind a router that allows outbound traffic only, runs the same six steps with no local server to maintain. Pick the board for the ability to run your script language and to keep time across a power cut, since both the schedule and the timestamps depend on it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.