A tag is the single point of data that a SCADA system reads from the field, so adding one correctly is the foundational skill behind every screen, alarm, trend, and report you will ever build. The work is less about clicking through a wizard and more about answering a short list of questions honestly: which device holds this value, where in that device does it live, what kind of number is it, and what does that raw number mean in real-world units. Get those answers right and the tag reads a clean, sensible value the moment you save it. Get any one of them wrong and the tag reads garbage, or worse, reads a plausible-looking number that is quietly off by a scale factor and misleads everyone downstream. This guide walks through adding a single tag by hand, end to end, and explains why each field matters before you save.
How to add a tag to SCADA in one line: To add a tag to SCADA, choose the source device and the exact register or address that holds the value, pick a data type that matches how the device stores it, apply any scaling needed to convert the raw number into engineering units, set the units and a clear description, name it using your site convention, and then verify the live value reads a sensible number before you save. Adding one tag by hand is fine for a handful of points, but for dozens or hundreds you switch to a spreadsheet import instead.
Every tag has to point at a real place where its value lives, and that place is defined by two things: which device the value comes from and where inside that device it sits. The device is usually a driver or connection you have already configured, a PLC, an RTU, a flow computer, or a Modbus slave, so the first step when adding a tag is to select that existing device from the list. If the device does not exist yet, you cannot meaningfully add tags for it, because a tag with no reachable source is just a name with no value behind it. Selecting the right device also determines what addressing scheme you are about to use, since a Modbus device wants a register number while an OPC or native PLC driver wants a symbolic address or tag path.
The address itself is where most first-time mistakes hide. On a Modbus device you are picking a register or coil number, and you have to know whether the value lives in a holding register, an input register, a coil, or a discrete input, because the same numeric address means different things in each of those spaces. Vendors also disagree about whether register numbering starts at zero or one, which is the source of the classic off-by-one where a tag reads the value that belongs to its neighbor. The safe habit is to read the device's own register map, the document the manufacturer publishes listing exactly which value sits at which address, rather than guessing from a similar device.
It is worth slowing down here because the address is the one field you cannot sanity-check by eye later. A wrong data type or a wrong scale factor often produces an obviously silly number, but a wrong address frequently produces a believable one, a pressure that reads a plausible value that actually belongs to a temperature register two addresses away. That kind of error can survive commissioning and only reveal itself weeks later when an operator acts on a reading that was never what they thought it was. Confirming the address against the register map, and later confirming the live value makes physical sense, is the discipline that keeps a single wrong number from quietly propagating into alarms and reports.
Once the address is set, you tell the tag what kind of number lives there. A device might store a value as a 16-bit integer, a 32-bit integer spread across two registers, a floating-point number, or a single bit. The data type you choose has to match how the device actually stores the value, and when a value spans two registers you also have to get the word order right, because the two halves can be assembled high-word-first or low-word-first depending on the device. A mismatch here does not produce a subtle error; it produces a wildly wrong number, a temperature reading in the thousands, because the bytes were interpreted the wrong way. This is one of the fastest problems to catch, because the live value looks absurd the instant the tag connects.
Scaling is how you turn the raw device number into something a human can read. Many devices report a value as an integer that represents a scaled quantity, a pressure sent as tenths so that 1250 means 125.0, or a 4 to 20 milliamp signal delivered as raw counts that have to be mapped to an engineering range. In the tag you enter the scaling that performs this conversion, whether that is a simple multiplier and offset or a raw-to-engineering span. Alongside scaling you set the engineering units, the label such as psi, degrees Celsius, gallons per minute, or percent, that tells everyone what the number means. Units are not decoration; an operator staring at a bare number cannot tell a pressure in psi from one in bar, and a report that omits units is ambiguous by definition.
The last fields are the human-facing ones: the description and the name. A description is a short plain-language sentence that says what the point physically is, Well 3 discharge pressure rather than just PT-301, so that anyone browsing the tag list understands it without a lookup. The name is the identifier the whole system will use to refer to this tag forever, which is why it should follow the naming convention your site already uses rather than whatever is convenient in the moment. A consistent, structured name lets you find tags, group them, and read screens at a glance, while a one-off ad hoc name becomes a small permanent nuisance that everyone has to work around.
The single most important step when adding a tag is the one people skip: before you consider the tag finished, look at the live value it reads and confirm it makes physical sense. A pressure tag on a running pump should read a believable pressure, not zero, not a maximum, and not a number three orders of magnitude off. Most SCADA tools also attach a quality flag to each value, good, bad, uncertain, or a communication fault indication, and a tag that reads bad quality is telling you the address, the device, or the connection is wrong even if a stale number is still displayed. Verifying both the value and its quality at the moment you add the tag is how you catch an addressing or scaling mistake while it is cheap to fix, rather than after it has been built into a screen.
This verification step is also where the field and the office finally agree. The cleanest way to confirm a new tag is to have someone at the device create a known condition, open a valve, run a pump, force a value, while you watch the tag respond, so you know beyond doubt that the point you added tracks the thing you meant. In a cloud SCADA platform such as Merobix, that live value from a remote site appears in the browser the instant the tag connects, so an engineer configuring a tag from the office and a technician standing at the RTU can verify the same reading together over the phone without anyone driving anywhere. Confirming the value end to end is what turns a configured tag into a trusted one.
Adding a tag by hand is the right approach when you have a few points to bring in, a single new transmitter, a handful of extra registers on an existing device, because the per-tag care of choosing the address and checking the value is exactly what those points need. But the same manual process becomes painful and error-prone at scale, and nobody should click through a wizard two hundred times to onboard a full flow computer or a whole new site. For that you switch to a bulk import, defining all the tags in a spreadsheet with columns for name, address, type, scaling, and units, then importing them in one pass with validation. The single-tag skill in this guide is what makes the spreadsheet correct, because every column in that import file is one of the decisions you just learned to make by hand.
The most damaging mistake is a wrong address, because it often produces a plausible-looking number rather than an obvious error. A tag pointed one register off can read a believable value that actually belongs to a different point, and that can survive commissioning unnoticed. The defense is to confirm the address against the device's published register map and to verify the live value makes physical sense before saving.
The data type has to match how the source device stores the value, which is documented in the device's register or address map. A value might be a 16-bit integer, a 32-bit integer across two registers, a floating-point number, or a single bit, and for two-register values you also have to set the correct word order. A mismatch usually produces a wildly wrong number, so an absurd live value right after connecting is a strong sign the type or word order is wrong.
Add them one at a time when you only have a few points, because the per-tag attention to address and live value is exactly what a small number of new tags needs. Switch to a bulk spreadsheet import when you are onboarding dozens or hundreds of tags, such as a full flow computer or a new site, since clicking through a wizard hundreds of times is slow and error-prone. Understanding how to add one tag by hand is what lets you build a correct import file.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.