In simulator builds 2.72, 2.73 and 2.77, an edit followed by Enter, a mouse-wheel scroll and a second edit can draw the edit box on the row the previous edit used, while the value still writes to the correct tag. Identify the edit target by tag name, record the value before and after, and restart the simulator when the box lands on the wrong row.
After you change a tag value in the HMI simulator, press Enter, and turn the mouse wheel without clicking anywhere else, the next edit box can open on the row the previous edit used instead of the row you double-clicked. The value still writes to the correct tag. Builds 2.72, 2.73 and 2.77 are the builds the reports name. This page gives the exact sequence, a worked example with the arithmetic, the checks that separate a misplaced box from a write to the wrong tag, and the way to keep a simulation session moving while the defect is open. One rule runs through all of it: identify the edit target by tag name, never by where the box appears.
Why does the HMI simulator draw the edit field on the wrong row?
It is a display defect in the simulator, not a tag fault: after an edit, Enter and a mouse-wheel scroll, the simulator draws the edit box on the row the previous edit occupied, and builds 2.72, 2.73 and 2.77 are the reported ones.
Two positions sit on a scrolled tag list: the screen row that displays a tag, and the position where the simulator opens the edit box. In this defect the two come apart. The box is drawn at the position the tag occupied when the last edit closed, while the write follows the tag you just double-clicked. So the box position is a fact about drawing, and the tag value is a fact about the project. Read the tag, ignore the box position.
The trigger is narrow. Every reported case runs the same order: edit a value, press Enter, roll the wheel with no click in between, then edit again on the same visible tag. Other ways of reaching the second edit are unreported, so if a box misplaces after a scrollbar drag, give it the same response: stop editing by row and restart.
How do you reproduce the wrong-row edit field on purpose?
You need a screen with a large tag count, a numeric tag placed at least 2 rows clear of the top and bottom of the visible list, and this exact order of actions: edit, Enter, wheel scroll, second edit, with no click in between.
- Open the project in the simulator and go to the screen with the largest tag count. The reports come from screens holding many tags, mostly numeric, because the list has to scroll while one tag stays in view.
- Pick a numeric tag at least 2 rows clear of the top and the bottom of the visible list. A tag at the edge scrolls out of view before the sequence completes.
- Write down the tag name and its current value.
- Double-click the tag's value, type a test value, and press Enter.
- Without clicking anywhere else, roll the mouse wheel to move the list a small amount. At the Windows mouse default of 3 lines per wheel notch, 1 notch is enough.
- Find the same tag by name and double-click its value again.
- Look at the row the edit box opens on. The reported defect puts it on the row the tag occupied at the previous edit, which after a 1-notch scroll sits 3 lines below the row you clicked.
Check: if the box tracked the double-clicked row, your build has not triggered it today; log the build from the about screen and move on. If you cannot tell with confidence which tag you double-clicked, stop the test.
What does the defect look like in a worked example?
In this example a screen holds 40 numeric tags, the test tag sits at screen row 12, the value goes from 0 to 50, and after a 2-notch wheel scroll the edit box opens 6 lines below the row you clicked.
Call the tag OVEN_SP and one of its neighbours PART_CNT; both names are invented for the example. The list shows about 20 rows at a time, and the Windows mouse default moves 3 lines per wheel notch.
- Edit: double-click OVEN_SP's value at screen row 12, type 50, press Enter. OVEN_SP occupies screen row 12 as the edit closes.
- Scroll: roll the wheel 2 notches with no click in between. The list moves 2 notches x 3 lines per notch = 6 lines, and OVEN_SP now displays at screen row 6, because 12 - 6 = 6.
- Second edit: double-click OVEN_SP's value at screen row 6. The box opens at screen row 12, the position OVEN_SP held at the last edit, 6 lines below the row you clicked. Screen row 12 now displays PART_CNT, so the box appears to sit on PART_CNT's row.
- Verify: type 75, press Enter, then find OVEN_SP by name. OVEN_SP reads 75 and PART_CNT is unchanged. The write followed the tag; the box followed the old position.
The offset equals the scroll distance: 2 notches x 3 lines per notch = 6 lines. Scroll 3 notches and the box opens 9 lines below the clicked row, because 3 x 3 = 9. What moves the offset is only how far the list travelled between the two edits.
The failure case: if PART_CNT reads 75 after the edit, the write went to the wrong tag. That is not this defect. Stop the session and check the screen's tag bindings.
Which simulator builds show it, and how do you check yours?
The reports name builds 2.72, 2.73 and 2.77 of the simulator software, so read your build from its about screen before you classify the fault, and run the sequence once if your install is not one of the three.
Only the three named builds carry the report. Nothing documents the builds between them or anything newer, so one controlled run of the 7-step sequence decides it for your install. A box that tracks the clicked row means your build is clear today; a box on the old row means you have the defect, whatever number the about screen prints. Read the maker's release notes for a fixed-defect entry on list drawing or the value edit box, and after any update rerun the exact sequence once. The box position during that rerun, not the version number, is the verdict.
How do you tell a misplaced box from a write to the wrong tag?
Check the tag, not the row: open the tag list after each test edit, read the value on the tag you named, and treat a value on a different tag as a stop-and-investigate fault, not a drawing problem.
- Box opens on the old edit row after edit, Enter, wheel scroll, second edit. The documented simulator defect. Continue, but name every target.
- The named tag shows the value you typed. The write went where it should. Only the drawing was wrong.
- A different tag changed, or the value reverts after you enter it. Not the drawing defect. Stop and find what owns the tag; PLC tag value changes back after an HMI write: find what owns the tag walks that check.
- The tag still shows the old value after a correct write. A stale display is a separate fault with its own walkthrough: HMI numeric displays show old values after a screen change.
One check sits behind all four lines: read the value on the named tag, then read the row. Name and value agree, continue; they disagree, stop editing and keep the reproduction details.
How do you keep editing when the box lands on the wrong row?
Stop editing by row, switch to editing by tag name, and restart the simulator once the box misplaces itself: a fresh session reopens the list at its start position and gives the edit box a clean position to track.
- Stop value entry the moment the box opens on a row you did not double-click.
- Record five things: the simulator build from its about screen, the screen name, the tag count on the screen, the action order, and the tag name with its value before and after.
- Close the simulation and start it again.
- Run one controlled edit on a clearly named tag. The box should open on the double-clicked row and the named tag should show the new value.
- Continue with a name check after each edit. If the box misplaces on a fresh session, stop simulation-based value entry and send the recorded details to the maker's support channel.
Recommendation: Treat the edit box position as unreliable in simulation after any edit, Enter, wheel-scroll sequence. Identify the target by tag name, record the value before and after, restart the simulator when the box lands on the wrong row, and resume only after one controlled edit on a named tag has passed. On a build other than 2.72, 2.73 or 2.77, run the 7-step reproduction once before you trust row positions in a long editing session.
Does a simulator defect mean the panel on the wall has it too?
No. The defect is in how the simulator draws its tag list on the PC; a panel has to be tested on its own screen, and a wrong value at the machine needs its own runtime check.
The reported cases all describe the simulator's list display, and the writes inside the simulation still land on the correct tag. Keep the two investigations separate. A machine value that looks wrong while a simulation session is open gets checked at the runtime display through the normal authorized process. If the simulator shows no live data at all, that is a different fault with its own checks: why an HMI simulator shows no live PLC data. A deployed panel that misplaces an edit box or shows a wrong value on its own screen is a runtime symptom, documented and tested on its own; the simulator diagnosis does not carry over.
How do you verify a simulated value change safely?
Change one named tag at a time, enter a value you chose for the test, and record the value before and after, so a misplaced edit box can never be confused with a process change.
Use a distinctive number: 50 where the live value is 0 separates your write from any live change. If OVEN_SP reads 50 after your edit, you did that; if it reads 50 after an edit you did not make, someone else owns the tag. Keep each edit on one line of the record: tag name, value before, value after, so a line reads OVEN_SP, 0 to 75, and can be checked at a glance.
If the simulator talks to a live line, stop before entering test values unless the approved operating procedure permits them; on live equipment, the process owner owns the test values.
The decision, case by case: a box on the old row with the named tag changed is the documented defect, so continue with name-based editing or restart; a box on the old row with a different tag changed is a stop, and the screen's tag bindings get checked; a box that tracks the clicked row means the build is clear today, and the sequence needs one rerun after any software update.
Questions
Does this defect change what the connected PLC receives?
In the reported behavior, no. The edit box is drawn on the wrong row inside the simulator, while the entered value reaches the tag you double-clicked. A wrong value at a connected PLC is therefore its own investigation: check what owns the tag, the screen's tag bindings, and which screen was active before you connect the symptom to the simulator's drawing defect.
What should a defect report to the software vendor contain?
Send the simulator build from its about screen, the screen name and its tag count, the exact action order of edit, Enter, wheel scroll with no click, and a second double-click, the tag name, and the value before and after. The sentence that changes how the report is classified is an extra one: the write still reached the correct tag, which files it as a drawing defect instead of a tag-mapping fault and lets support duplicate it from the sequence alone.
Why does the tag count on the screen matter?
The list has to scroll for the sequence to exist. With 40 tags on one screen the list moves under the wheel; a short list that never scrolls leaves every edit row where it was, so the misplaced box cannot occur. The reports come from screens with many tags, mostly numeric, and screens with many non-numeric tags are not covered by the reports.
Would scrollbar dragging trigger the same misplaced box?
The reports describe mouse-wheel scrolling with no click between the two edits, and other ways of moving the list are not covered. If the box lands on the old row after a scrollbar drag or an arrow-key scroll, respond the same way: stop editing by row, restart the simulator, and continue with a name check after each edit.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.