Fix an imported HMI tag that ignores PLC register writes

Match the symptom before you edit anything

A write failure has five signatures, and only the first is fixed in the tag database.

• Entry accepted, register unchanged, tag was imported. The tag-record fault. The imported single-word records that failed had a blank datacount; working records show 1. Run the export-edit-import below.
• Entry accepted, register unchanged, tag was created by hand. Check the object-to-tag link first, then the address type. A screen object cannot force a physical input; it can write only a data word the logic treats as writable.
• Register changes but the number on screen is absurd. A huge positive value after an entry is a data format mismatch, so set the tag's signed decimal data format to match the PLC data. The write path is fine.
• Reads and writes both fail, or a fault repeats on a timer. Communications. Check the protocol driver before touching the tag database.
• Imported tag does nothing at all, name lowercase, editor version 1.1.1.3a. The capitalization import bug. Capitalize every name before import; the fix is folded into step 4 below.

Two PLC-side checks belong here because they produce the same symptom. Confirm the target is a data word, and confirm no rung writes that word every scan: an entry that lands and is overwritten on the next scan looks identical to an entry that never lands. Watch the register in the PLC programming software while an operator makes an entry; if the value jumps to the entered number and back, the fix is in the ladder. The reported case passed both checks, valid unallocated addresses, which is what pointed at the record.

The fix: set datacount to 1 and import again

1. Export a backup. Export the tag database as it stands and keep that file unedited. If an import rejects your corrected file or changes records you did not touch, restore from this copy.
2. Export the editable copy. The tag database exports to a spreadsheet file with a .csv or .xls extension, and imports back from the same format. Open the export and find the failing tag's row.
3. Compare rows, then edit one field. A working single-word tag shows 1 in datacount; the failing imported tag shows a blank. Set datacount to 1 on the failing tag's row. Change nothing else on the row, and do not copy the value onto tags with other data sizes.
4. Capitalize every tag name on version 1.1.1.3a. That build carries a known import bug: lowercase names come in, but the lowercase tags do not work correctly. Treat capitalization as a standing rule for imports on that version, and confirm the installed version before blaming the bug on any other build. Lowercase identifiers that import quietly and never run appear in other engineering tools as well, repaired there with an explicit case-sensitivity switch for lowercase symbol names.
5. Import through the tag database import. In this editor the path is File > Import > Tag Name Database. The import is built for a tag name database exported from the PLC programming package, and the help file notes that only tag names with nicknames come across, so a tag missing from the export usually has no nickname on the PLC side.
6. Recheck the object. Open the data-entry object and confirm it still names the intended tag, now capitalized.

Recommendation: when an imported single-word data-entry tag accepts an entry but the register will not change, edit the record before touching the PLC. Export the tag database, set datacount to 1 on the failing tag, capitalize every imported name when the editor carries the lowercase-name import bug, import again, and verify each tag with one controlled entry. Keep the original export as the backup, and reassign an address only after the test shows the entry landing and being overwritten by logic.

Example: a setpoint entry that never reaches the register

A mixer recipe holds its batch weight setpoint, a value in kilograms, in one 16-bit data word; a word in a PLC data area is 16 bits, or 2 bytes. The operator screen has a single-word data-entry object for it, imported from the PLC programming package, and the tag record arrived as setpoint, lowercase, with datacount blank.

The object displays 250 kg. The operator types 300 kg and presses Enter. The object accepts 300 kg, and the register in the PLC programming software still reads 250 kg after 5 seconds of watching. The address is a 16-bit data word and no rung writes it, so the PLC side is clean.

Export the tag database. Two rows tell the story:

Set datacount to 1 on the setpoint row, capitalize the name to SETPOINT because the editor is version 1.1.1.3a, save the .csv file, and import it through File > Import > Tag Name Database. Enter 300 kg again: the register now reads 300 kg, and the screen shows 300 kg after the entry. Then run the same one-entry test on each remaining imported tag; the correction applies per record, and a repaired row does not carry over to its neighbors.

Verify each tag with one controlled entry

Test one tag at a time with a value the process tolerates: a setpoint moved one small step, such as 10 kg on a batch scale that runs 0 to 500 kg, a number well inside the range the logic expects. Watch the register in the PLC programming software as the entry lands, and give it at least 5 seconds before judging. The screen and the register should agree, and the value should stay.

If the register drives equipment, run the test where a wrong value gets caught before it matters: machine idle, or the entry checked against the process limit before anyone acts on it. Once writes work, clamp the entry in ladder logic so an out-of-range number typed at the screen cannot reach the process; the pattern is in clamping HMI numeric entry limits in ladder logic.

If the entry lands and then reverts, a rung is overwriting the word every scan and the fix is in the ladder. If nothing lands at all after the reimport, recheck the row's datacount, the name's capitalization, and the object-to-tag link, in that order.

Keep the workaround narrow

This is a spot fix for imported records. Change only the failing rows, keep the unedited export as the backup, and leave working records alone. The datacount correction shown here covers single-word data-entry tags, so do not scale the value up to a wider tag. The capitalization rule belongs to the affected build; confirm the editor version before renaming anything on its account. Reassigning registers was never the fix in the reported case: the addresses were valid and unallocated, and the record metadata was the fault.

Questions