A panel talks to a controller you wrote yourself when its manual documents a serial Modbus RTU driver and a role that complements yours. Set both ends to one setting such as 19200 baud, 8 data bits, even parity, 1 stop bit, agree on the register offset, and bench-test one read-only register before you draw screens. The PLC compatibility list is about built-in drivers; the open protocol is what lets an unlisted controller talk to the panel.
A controller you wrote yourself can drive a commercial operator panel. The panel's PLC compatibility list is not the gate it looks like: it names the ready-made drivers the panel ships with, and a driver for your own firmware will not be on it. The part that matters is the panel's documented protocol, and the open one is Modbus RTU on a serial port. Choose a panel whose communication manual documents a serial Modbus RTU driver, set the panel and your controller to one identical serial setting, and put them on opposite sides of the conversation: panel as master, controller as slave. Then agree on register addressing before you draw a single screen. The sections below cover the choice, the settings, the offset trap, and a worked link budget for one register polled at 19200 baud.
What decides the choice
Four checks, in this order:
- A documented protocol. An RS-232 port is the electrical connection. The protocol is the message set that travels over it. Two devices with RS-232 ports and no shared protocol sit silent. Read the communication manual for the exact panel model before the panel goes on your shortlist, and note which protocols it documents and what each one demands from the other end.
- Complementary roles. Modbus is a master-slave conversation. The master sends each request; the slave answers it. Panels with a Modbus driver usually poll, which makes them the master, and your controller becomes the slave. Take the role from the panel's manual, then build the other side in your firmware. Never infer the role from the word Modbus on a datasheet.
- Serial settings both ends can match. Baud, data bits, parity, stop bits and station address must be identical at both ends. Confirm the panel lets you set each one, because some drivers fix some of them.
- A register map you control. Decide what the controller exposes, at which addresses, read-only or writable, before anyone opens the screen editor. The screen work comes after the link works; planning a touchscreen operator interface covers layout and touch once the data path is settled.
Panel types that can talk to a controller you wrote
| Panel type | How it talks | Pick it when | Watch |
|---|---|---|---|
| Serial Modbus RTU panel | A documented Modbus driver on RS-232 or RS-485; the panel usually polls as master | Your firmware can frame replies: silent gaps, CRC, station address | Confirm the panel's role and its configurable settings in its manual |
| Panel with a published byte protocol | The maker documents a command-and-response byte format in full | You want a small protocol stack and will stay on that maker's panels | The format is tied to that maker and to the manual revision |
| Panel sold only on a PLC compatibility list | Drivers for named PLC families, no open protocol documented | A commercial PLC is on the other end | Nothing documented to implement your controller against |
The first row is the usual answer. Modbus RTU is an open specification: any controller that frames its replies correctly, answers inside the silent-interval rules and computes the CRC right is a valid slave, whether or not it appears on any compatibility list. The list describes the drivers built into the panel; the open protocol is the path for everything else.
Set both ends to one serial setting
The serial specification defines the RTU character: 1 start bit, 8 data bits, least significant bit first, then a parity bit, then the stop bits, 1 stop bit when parity is used and 2 when parity is off. A common power-up default on panels is 9600 baud, 8 data bits, no parity, 1 stop bit. You do not have to live with a default. Pick one setting and enter it in the panel's communication setup and in your firmware's serial configuration. 19200 baud, 8 data bits, even parity, 1 stop bit, written 8-E-1, is a good working choice and the one used in the example below.
Give the controller a station address in the 1 to 247 range the serial standard allows, and enter the same address in the panel. Frames ride between silent intervals: the RTU rule ends each frame with a gap of 3.5 character times, and documentation of the standard puts the minimum silent period at 1.75 ms. Your firmware must hold each reply inside one frame and keep quiet between frames, or the panel reads the bytes as garbage.
The panel is the master, your controller answers
Most Modbus panels poll continuously and treat your controller as a slave, so the firmware work is a responder: watch for a complete frame, check the CRC, match the station address, reply inside the gap rules. That is the same job as putting an HMI panel on a custom Modbus RTU slave, and the HMI panel to microcontroller Modbus RTU connection walks the firmware side for a small chip. When the panel goes silent or reports address errors after bring-up, the no-reply and address-error fix covers the usual causes in the order to check them.
The 40001 register offset
Panel register sheets usually number holding registers from 40001. On the wire, the address is the sheet number minus 40001: sheet entry 40001 is address 0, and 40011 is address 10. Your firmware stores data at plain addresses, so write the mapping down once in the register map and follow it on every screen object.
The classic slip is one position off. It still returns data from the neighbouring register, so the link looks healthy while the screen shows the wrong tank. If values come back wrong on a link you believe is clean, compare the numbering conventions and the data width first; nonsense numbers from a BCD analog register is the same class of fault one layer up.
Example: one level register polled at 19200 baud 8-E-1
Scenario: a tank level sits in one holding register on your controller, and the panel updates a bar graph twice a second.
Settings at both ends: 19200 baud, 8 data bits, even parity, 1 stop bit, station address 5.
Character maths. The RTU frame format is 1 start bit + 8 data bits + 1 parity bit + 1 stop bit, so each character is 11 bits. At 19200 baud the bit time is 1 / 19200 = 52.1 µs, so one character is 11 × 52.1 µs = 573 µs. The 3.5-character silent gap between frames works out to 3.5 × 573 µs = 2.0 ms.
Wire time per poll. A one-register read request is 8 bytes (station, function, start address, register count, CRC) and the reply is 7 bytes (station, function, byte count, 2 data bytes, CRC). That is 15 bytes × 11 bits = 165 bits, and 165 × 52.1 µs = 8.6 ms on the wire. Add the gap before the request and the gap before the reply: 8.6 + 2.0 + 2.0 = 12.6 ms, call it 13 ms per poll.
Margin check. Polling every 250 ms keeps the line busy 13 / 250 = 5% of the time. Reading four registers in one request raises the reply to 13 bytes, and the poll still lands near 16 ms, about 6% occupancy. The line has room for the whole register map at this rate.
Addressing check. The panel's sheet lists the level as 40011. 40011 − 40001 = 10, so the request carries address 10 and the firmware keeps the level at index 10 of its holding-register array. If the sheet had read 40010, the request would carry address 9 and the bar graph would show the neighbouring value.
Decision: at 13 ms per poll against a 250 ms scan, a mid-range Modbus RTU panel and a home-grown controller have an easy margin. Size the register map to fit one request where you can and keep the poll interval at 250 ms or slower.
When a different screen fits better
If the other end turns out to be a commercial PLC after all, buy the panel from that PLC's supported list and skip the custom firmware work entirely.
If the panel must write setpoints into the machine, plan the write path now: separate writable control registers from read-only status, validate every written value in the controller, and bring writes up last, with a harmless value and machine outputs inhibited.
If what you want next to the machine is a status or notice board with no controller behind it, that is a signage display. Our panel-mount Android displays play images and video from microSD or USB with no subscription; they are not operator interfaces, and their HDMI port is an output only.
What to ask for before you order
- The communication manual for the exact panel model and revision, showing the Modbus RTU driver, the panel's role, and every serial setting it lets you change.
- The register sheet, so you can check its numbering convention against your map before any screen exists.
- The range of the panel's response-timeout setting, and what the screen shows when a poll times out.
- The serial connector type and the manual's wiring drawing for the exact model, and whether the driver needs flow control. RS-232 is point to point, one panel per port, with TX and RX crossed between the ends; follow the manual's wiring drawing, not the connector's shape.
- From your side, a CRC check: capture one frame from the panel on a bench link or take a known-good frame, and confirm your routine matches it byte for byte.
Bring the link up in this order: one read-only register first, then one bounded write with the machine outputs inhibited, then pull the cable and confirm the panel shows loss of communication. Move to screens only after all three behave.
Recommendation: Shortlist panels whose communication manual documents a serial Modbus RTU driver with the panel as master. Set both ends to 19200 baud, 8 data bits, even parity, 1 stop bit, give the controller a station address in the 1 to 247 range, and wire the RS-232 link point to point with TX and RX crossed. Bench one read-only register first, machine outputs inhibited, and draw screens only after that read holds steady.
Questions
Can the panel and my controller share an RS-485 bus with other devices?
Yes. RS-232 is point to point, one panel per port. On RS-485 the panel can poll your controller alongside other slaves, each with its own station address in the 1 to 247 range the serial standard allows. Give every device a unique address, keep the bus as one line with short stubs, and terminate both ends of the segment, commonly 120 ohms at the usual baud rates.
What response timeout should the panel use?
Set the panel's response timeout between 300 and 500 ms for a link like the worked example. A poll at 19200 baud completes in about 13 ms, so the timeout never fires in normal operation; it only reports a lost reply. Too short a setting turns a slow scan into nuisance alarms and too long leaves the screen stale after a fault, so measure your controller's worst-case reply time and stay comfortably above it.
Can the panel write setpoints into my controller safely?
Yes, once reads are working and steady. Expose the setpoint as a writable holding register kept separate from read-only status, and validate every written value in the controller before it reaches outputs: reject anything outside the permitted range and fall back to a safe value when the link goes stale. Bench-test the write with a harmless number first, with machine outputs inhibited.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.