An HMI tag refuses deletion while any project element still references it. List every use with the project's cross-reference tool, including alarms, events and system screens, replace the tag at each one with a confirmed replacement, then delete the old entry once the list reads zero uses.
A tag that refuses to delete is not a corrupt database. The software blocks the delete because at least one element in the project still references the tag, and deleting the object you can see leaves the references you cannot see. The reliable order is fixed: list every use with the project's cross-reference tool, replace the tag at each one, then remove the entry from the tag-name database. The worked case below is an 8-inch panel project on software version 2.75, where the leftover reference turned out to be an alarm configured long before and never revisited. Budget one work session of about 20 minutes for the cleanup and keep the backup until the line has run one full shift of 8 hours after the change.
Why the software refuses the delete
The message says the tag is associated and cannot be removed. Read that as a dependency report. A panel project keeps two things: the tag-name database and a set of references to those tags from screens, alarms, events and system screens. Deleting a screen object clears one reference. The database delete stays refused while any reference remains, because the check exists to stop objects ending up with no tag behind them. Retrying changes nothing: the reference count has not moved. Waiting 10 minutes and retrying also changes nothing when the blocker is a reference, so use that quick test to tell a leftover use from a session lock before you go further.
What each symptom points to
- Delete refused with the associated-tag message. At least one reference is left. The target of the search is a use, not a setting.
- The object you removed is gone and the delete still refuses. The remaining use sits off-screen. Alarms, events and system screens hold tag references that no screen shows. An alarm set to send an e-mail on alarm is a typical leftover, because it is configured once and rarely opened again.
- The delete is refused after a network drop on a client project. The link went down and the session ended; deletes stay locked until the timeout clears. Restore the link first.
- The tag vanished from the database after the communications device was deleted, but screens still name it. Deleting the device empties the tag-name database while references on screens already created stay in place. Those screens need their references rebuilt.
Find every use before you change anything
Save a dated copy of the project first, and export the tag database to CSV so the cleanup has a before-and-after record of every name, address and source.
Then open the cross-reference list. In this software it sits on the Tool menu: Tool > Tag Cross Reference. Sort by tag name and read down to the tag you want gone; the same list offers a sort by screen name when several screens share the tag. Double-clicking a listed line jumps to the screen and object that holds the use. Other packages reach the same list from the tag itself: right-click the tag and choose Cross-references, or select the tag and press F11. Some offer a form that searches tags or text strings and returns the results in a spreadsheet-style list.
Read the whole list before you edit anything. Note each use: which screen, which object, which alarm, event or system screen. If a listed use is an alarm or event you did not build, resolve what it controls before touching it; removing the function to free the tag deletes its notification with it. A listed use can also sit on an object the editor hides, and the article on selecting hidden HMI objects in the editor with cross reference shows how to reach one once the list names it.
Example: one alarm function holds the tag on the 8-inch panel at version 2.75
Inputs. Panel: 8-inch. Software: version 2.75. Both figures come from the project where this block appeared. The tag is referenced by one screen object, already deleted, and by one alarm event set to send an e-mail on alarm. The cross-reference list for the tag shows 2 uses: one on the screen object and one in the alarm event.
Rule. The database delete is refused while the cross-reference list for the tag shows 1 or more uses. It is accepted at 0 uses.
Arithmetic. Start: 2 listed uses. The screen object is deleted: 2 - 1 = 1 use left, so the delete is refused and the message repeats, which is exactly what the project showed. The alarm event is removed: 1 - 1 = 0 uses.
Result. At 0 listed uses the software has no association left to enforce. The delete from the tag-name database is accepted, and the tag is gone once the project is saved. On this project the whole cleanup ran inside one work session of about 20 minutes from opening the list to the accepted delete.
Decision. The go condition for the delete is a cross-reference count of exactly 0 uses, confirmed on 2 consecutive runs of the list taken about 2 minutes apart. If the e-mail-on-alarm must keep working, remove nothing: create a replacement tag, point the alarm event at it, and the old tag's count still reaches 0 uses.
Replace every use, then delete the tag
- Create the replacement tag. Type its address or data source from the project's own configuration; never copy a value you cannot point to on the controller or device.
- Open Tool > Tag Cross Reference, sort by tag name, and work down every line that names the old tag: screens, events, system screens.
- Change each use to the replacement tag. Changing a reference keeps the function; the alarm or event keeps its behavior under the new name.
- Run the cross reference again for the old tag name and give any late-listed use the same treatment.
- When the list reads 0 uses on 2 consecutive runs, delete the old tag from the tag-name database and save the project.
A name match is not validation: confirm the replacement points at the intended controller or device data before trusting the screens and alarms now sitting on it.
After the delete
Run the cross reference one last time and confirm the old name returns no lines. Check the database no longer lists it. Open every object you changed and confirm it displays the replacement's values as they change at the controller; give the controller 5 minutes of live data so you see values move, not just a static first read. Put the touched alarm and event functions through the project's normal validation before the line goes back to work.
When the references are not the blocker
A client session that lost its link. One vendor documents the lock directly: after a network cable removal or a client power loss, tags cannot be deleted until the DCOM timeout occurs. The cross-reference list can read 0 uses and the delete still refuse until that timeout fires. Restore the link, let the client session re-establish, then retry.
The connection-delete shortcut. Removing the unit from the panel manager empties the tag-name database, but every reference on screens already created stays, and the port's IP address and connection settings are gone with it. Capture those settings before any such delete, rebuild the connection, then handle the screen references the normal way. Treat it as a deliberate communications rebuild, never as tag cleanup.
The decision
Recommendation: replace, then delete. Build the replacement tag with a confirmed address, redirect every use the cross-reference list names, including alarms, events and system screens, and remove the old entry only when the list reads 0 uses on 2 consecutive runs. If a listed use is an alarm that must keep running, repoint it to the replacement instead of deleting it. Keep the connection delete for jobs where you are rebuilding that link on purpose, and capture its settings first.
Questions
Can I delete the alarm function instead of replacing the tag?
Only if the function is genuinely retired. Deleting it frees the tag but removes its e-mail notification with it, and anything that depended on that message stops receiving it. If the alarm must keep working, create the replacement tag, point the alarm event at it, confirm the replacement's address or source in the project, and the old tag's cross-reference count reaches zero without losing the function.
The cross-reference list is empty and the delete still fails. What now?
On a project that runs as a network client, the block can be the session rather than a reference: the vendor documents that tags cannot be deleted until the DCOM timeout occurs after a network cable removal or a client power loss. Restore the link, let the client reconnect, and retry. If the delete still fails on a local project, keep a dated backup and take the question to the software vendor's own support channel.
Should I back the project up before the cleanup?
Yes, and keep the copy untouched while you work. The cleanup edits alarms and events as well as screens, so repointing a function by mistake is easy to do and the backup is the way back. Running the project's normal validation with the backup in hand is the second check before the line returns to work.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.