HART Primary and Secondary Master Roles
HART allows two masters to talk to the same field device at the same time, which is why a technician can hook a handheld communicator onto a loop that a control system is already polling without either one locking the other out. Understanding the primary and secondary master roles explains how that coexistence works, and why setting the wrong role on a host can cause two masters to talk over each other. This page is for anyone commissioning a HART host or troubleshooting a loop where communication mysteriously stops when a second device is connected.
HART Master Roles in one line: HART supports two masters on one loop: a primary master, typically the permanently connected control or asset-management system, and a secondary master, typically a handheld communicator a technician plugs in temporarily. Each master is assigned a distinct role so the field device can tell them apart, and a token-passing arbitration lets them alternate turns on the wire without colliding, so both can communicate with the device concurrently.
Two Masters, One Field Device
In a HART network the field devices are slaves that only speak when spoken to, and the master is whatever host initiates the request-and-response exchanges. What makes HART unusual is that it allocates room for two masters, not one. The primary master is normally the fixed installation - a control system input, an asset-management server, a HART multiplexer, or a gateway - that is wired to the loop permanently. The secondary master is normally a handheld communicator or a laptop-based tool that a technician connects temporarily to check or configure the device.
The two roles are not interchangeable labels; they are distinct addresses in the protocol that let the field device recognize which master a given message came from and reply to the right one. This is what allows a technician's handheld to hold a conversation with a transmitter while the plant's asset-management system is also polling it. The device services both, keeping their exchanges separate. Setting a permanently installed host to the secondary role, or plugging in a handheld that is also configured as primary, causes a conflict because two devices then claim the same role.
The classic symptom of a role conflict is that HART communication works fine until a second master is introduced, then becomes erratic or stops. If a control system is the primary master and a technician connects a communicator that is misconfigured as primary rather than secondary, both try to own the same turn on the wire and their messages collide. The fix is to confirm each host is set to a distinct role, which is often the overlooked cause behind a handheld that suddenly cannot find a device it reached yesterday.
How Arbitration Keeps Them From Colliding
Two masters sharing one wire need a rule for who transmits when, and HART handles this with a token-passing arbitration between the primary and secondary masters. Conceptually the right to initiate a transaction alternates between them: one master takes its turn, completes an exchange with a device, and then yields, allowing the other master its turn. Because the turns alternate rather than overlap, the audio-band FSK signals of the two masters do not step on each other, and each gets predictable access to the field devices.
This alternation is also why adding a second master roughly halves the transaction rate each master gets. If a control system was polling a device at some rate on its own, connecting a handheld means the loop now interleaves both masters' exchanges, so the primary master's effective polling rate drops while the handheld is active. This is normal and temporary, but it is worth knowing when a loop that felt responsive slows down the moment a technician plugs in, because the slowdown is the arbitration doing its job, not a fault.
The arbitration only governs the masters; the field devices remain pure slaves throughout. This is a different mechanism from the collisions that plague a shared bus without proper turn-taking, which is why a well-behaved two-master HART loop does not suffer the kind of contention seen on an unmanaged multidrop bus. If you are debugging why a handheld cannot see a device at all, the role and arbitration picture here pairs naturally with the troubleshooting page on a HART communicator that cannot find the device.
Frequently Asked Questions
Can a control system and a handheld talk to a HART device at the same time?
Yes, that is exactly what the two master roles enable. The control system acts as the primary master and the handheld communicator as the secondary master. HART's token-passing arbitration alternates their turns on the wire so both can hold concurrent conversations with the same field device without their signals colliding.
What happens if two HART masters are both set to primary?
They conflict. Two masters claiming the same role both try to own the same turn on the wire, so their messages collide and communication becomes erratic or stops. The usual scenario is a handheld misconfigured as primary connecting to a loop where a control system is already the primary master. Setting each host to a distinct role resolves it.
Does connecting a handheld slow down HART polling?
Slightly, and temporarily. With two masters active, the token-passing arbitration interleaves both masters' exchanges, so the primary master's effective polling rate drops while the handheld is connected. This is normal behavior of the arbitration, not a fault, and the rate recovers once the handheld is unplugged.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.