Wi-Fi gives a maintenance cart HMI a network path, nothing more. The screen shows live machine status when it runs its own PLC driver session over the plant Ethernet, the controller serves a second client, and the measured radio signal stays above -67 dBm at every parking spot. Treat the 8-inch panel's serial pass-through as a programming route unless its manual states it carries runtime data.
The arrangement is a common one: an 8-inch touchscreen off the PLC serial port runs the machine, and a 6-inch screen on the maintenance cart follows the same data over the plant's wireless network, so the crew knows when a line goes down and maybe why. Two words carry the whole load: same data. Wi-Fi hands the cart screen a network path. Machine values reach the cart only when the cart screen runs its own PLC driver session to a port the controller serves, and only where the radio signal survives the trip from the access point to every spot the cart parks. The pass-through function on the panel's serial side exists for programming access, and it carries runtime data only where the manual says so. Here is the decision, with the numbers that settle it.
What decides what the cart screen shows
Three checks, in this order.
A driver that speaks the controller's protocol over Ethernet. Find the plant controller's Ethernet protocol and exact model in the panel's protocol driver list. That check comes before any tuning: a screen without the driver shows a joined network and no data.
A port the controller serves for a second client. An Ethernet port on a controller commonly serves several simultaneous sessions, so the 8-inch panel on the serial side and the cart screen on the Ethernet side can each hold a session of its own. A serial port generally serves one master, which is why the cart cannot simply join the panel's cable. The session-count arithmetic repeats for every later device too, and the case of a panel holding the port a SCADA node wants is its own walkthrough.
A network path that holds. The cart's wireless association must survive every parking spot, the addresses must route between the cart network and the controller, and the firewall between them must allow the ports the panel family's system manual names for its drivers. Read the port list from that system manual and open those ports on the firewall before the first test; the engineering tool's own documentation plays the same role for the sessions it opens.
What pass-through is documented to do
Pass-through has one documented job in panel manuals: a programming device reaches the controller's serial port through the panel, so one cable run at the machine serves both the running screen and the laptop. Some controller families document that serial pass-through is unsupported altogether, so the pair needs two manual checks: the panel's communications section and the controller's port functions.
Unless a manual states that pass-through carries runtime data to a second screen, design the route as programming traffic only. A programming session opens on demand and ends; live values need a session that holds and refreshes for the whole shift. The cable physics agree: RS-232 was written around roughly 15 m of run, so the panel sits near the controller, and a cart roaming the building was never going to hang off that port. The cart's route has to be one of the standard paths to a controller over serial or Ethernet, and here the Ethernet one is the only candidate.
Routes for the cart screen, compared
| Route | What the cart screen shows | What it needs | The catch |
|---|---|---|---|
| Cart HMI with its own Ethernet driver over plant Wi-Fi | Live values and alarm text wherever the cart is in coverage | The controller's Ethernet protocol in the cart panel's driver list, a controller that serves a second session, agreed addressing and firewall ports | Coverage has to be measured at every parking spot |
| Serial pass-through through the 8-inch panel | Programming access to the controller's serial port; runtime data only where both manuals state it | Documented pass-through support in both manuals | Most pairs document programming use only, and a serial port serves one client |
| Wired drop at the cart's home position | The same live data with no radio variance | A copper Ethernet run to the parking spot, inside the 100 m segment structured cabling allows (90 m in the wall, 10 m of patch cords) | The cart stops where the cable ends |
| Fixed board in the crib | One glance at every line for the whole crew | Its own data source and display design | No use at the machine itself |
The first row is the design that meets the goal as written: know when a machine goes down, from anywhere the cart parks. The second row is a maintenance tool, not a monitoring design. The third row trades mobility for certainty. The fourth answers a different question, the crew-wide view, and it is a read-only process display by design.
Example: the radio budget at the cart's farthest parking spot
The inputs, and where each comes from:
- 25 m, access point to the farthest spot the cart parks. Scenario input: a typical bay span. Your survey measurement replaces it.
- 2400 MHz, the radio frequency this example budgets. Frequencies in this range travel through building materials better than higher ones.
- 20 dBm EIRP (100 mW) at the access point, a common configured level.
- 2 dBi of antenna gain at the cart panel, typical of an integrated antenna.
- -67 dBm, the signal floor Wi-Fi survey practice treats as the design target for reliable data traffic.
The rule in words: free-space path loss. Between two antennas in open air, loss in dB equals 20 times the base-10 log of the distance in metres, plus 20 times the base-10 log of the frequency in MHz, minus 27.55. Received signal equals radiated power, plus receive antenna gain, minus path loss.
The arithmetic:
- 20 × log10(25) = 20 × 1.398 = 27.96 dB
- 20 × log10(2400) = 20 × 3.380 = 67.60 dB
- Path loss = 27.96 + 67.60 − 27.55 = 68.01 dB
- Received signal = 20 dBm − 68.01 dB + 2 dBi = −46.01 dBm, call it −46 dBm
- Margin over the floor = −46 − (−67) = 21 dB
Result: in open air the cart sees about −46 dBm, 21 dB above the floor. What moves it: every doubling of distance adds 6 dB of loss, the slope of the formula itself, and every obstruction between the antennas spends the margin. A plant is not open air, so the arithmetic clears the floor only where the path stays clear.
Decision: walk the route with the cart and read the signal at each parking spot. Stronger than −67 dBm: that spot is fit for the cart screen's polling session. Weaker: give that bay an access point of its own. The extra radio is cheaper than a screen that drops off the network every time it parks behind the weld cell.
When to wire the cart instead
- The cart lives at one or two bays. A copper drop at the home position ends the radio question. Keep the run inside the structured-cabling segment limit from the table.
- Coverage fails at one bay. Add an access point serving that bay. Stretching one radio across a building it cannot cover produces a screen that reconnects at random; more radios at the places the cart parks is the fix.
- The controller has no Ethernet port. The supported route is a gateway the controller manufacturer documents, translating its serial protocol onto the plant network. The cart panel's driver list must name the gateway's Ethernet protocol too; verify that before buying.
- The crew wants one board for every line. That is the fixed crib board, and the board itself is shop-floor signage, built as a display, not as a machine HMI.
What the controller must record about a stop
The screen can only show what the program holds. Live values say the machine stopped; the cause lives in what the program latches at that moment: fault bits, alarm codes, the sequence step, a timestamp. If the program clears its faults without a history buffer, the cause dies with the condition, and no screen on any cart brings it back.
So read the program before the hardware order: list the tags it holds through a stop, map the cart screen to those same tags, and test one known fault with the machine in a safe state while you watch both panels. Where the controller keeps no history, panel families that offer data logging at the screen give you a documented fallback.
What to ask for before you buy
- The cart panel's driver list entry for your controller's Ethernet protocol and exact model.
- The controller manual's limit on simultaneous sessions per port, in writing.
- Both manuals' pass-through entries: the sentences that state what the function carries.
- A Wi-Fi survey taken with the cart in its real parking spots, guards and doors as they run.
- The tag list the program exposes through a stop: fault bits, alarm codes, step number, timestamp.
- The panel system manual's port list for the firewall between the cart network and the controller.
The decision
Recommendation: give the cart screen its own PLC driver session over the plant Ethernet, and design the serial pass-through out unless both manuals state it carries runtime data. Put the cart into service only where a measured signal stays above −67 dBm at every spot it parks, keep every control function on the 8-inch panel's local serial link, and read the cause of a stop from tags the program latches. If the cart serves one bay and coverage there is weak, run the cable and finish the job.
One safety rule sits beside this: machine control stays local. A link that can drop belongs on monitoring. Start, stop and anything the safety functions depend on stay wired at the machine.
Questions
Can the cart screen share the 8-inch panel's serial connection to the PLC?
A serial port serves one master, so the cart cannot join the panel's cable on its own. The documented ways a second device reaches that port are pass-through, where the panel manuals state what it carries, and nothing else. If the panel manual describes pass-through only as a programming route, which is the common case, the cart screen needs its own session on the controller's Ethernet side.
What should the panel manuals say before pass-through can carry runtime data?
Look in the communications sections of both manuals for a pass-through entry that names runtime or application data as carried traffic, states the protocols it supports, and states any limits on session count or update behavior. A pass-through chapter that covers only download, upload and programming access settles the question the other way: the function is for programming, and the cart screen needs a different route.
How many wireless access points does a maintenance cart route need?
Count the bays, not the building. Measure at every spot the cart parks and place an access point wherever the reading falls under -67 dBm; the free-space arithmetic gives the starting budget and the survey gives the answer. A single radio stretched past its coverage produces a screen that reconnects at random, and a reconnecting monitor reads as a machine that stopped reporting.
Does the wireless link change what the screen can do safely?
Keep the cart screen read-only for machine functions. Control commands over a radio link can arrive late or turn up after a dropout, so start, stop and anything a safety function depends on stay wired at the machine. A monitoring view that displays values and alarm text, with no write access to the controller, can ride the wireless network without touching the control path.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.