The blue you never chose is the panel's built-in flash color. The editor gives you no property to set it, so switch the object's flash off and let a PLC blink bit, such as a 1-second bit, swap the two state colors you configured. The colors then come from your states, the cadence from the PLC, and no unwanted color enters the drawing.
You set an HMI object to blink between red and yellow, and the panel blinks red and blue. The blue is not a setting you missed. The object's built-in flash picks its own alternate color, and the editor gives you no property to change it. The reliable fix is to stop using the built-in flash: toggle the object's two state colors from a PLC blink bit, a 1-second system bit or a self-resetting 500 ms timer. The panel then draws only the two colors you configured, at the rate your PLC sets.
Why the flash shows blue
The flash you enable on an object is drawn by the panel's runtime. It alternates the color you configured for the state with a second shade it chooses itself, and no property in the editor reaches that second shade. That is why the blue survives every appearance setting you touch, and why it shows up in the simulator just the same.
A few HMI packages do expose flashing characteristics per color setting. Read the help for your exact object type first: if a flash color setting exists there, the whole job is one property and you can stop reading.
Symptoms and what each points to
- Blue shows only while flash is on. The runtime is drawing its own alternate color. Your two state colors are correct; the flash pair is out of your hands.
- The simulator shows the same blue, on indicators and text objects alike. Changing object type or reinstalling the editor changes nothing. The flash drawing lives in the runtime, not in your object.
- Colors are wrong even with flash off. That is a state and color table problem. Fix the state colors first, then judge the flash.
- Two overlapping objects switched by a visibility bit blink unevenly. The PLC scan, the driver poll and the screen redraw run on separate clocks, so the bit toggles regularly while the picture wobbles. The same redraw path is behind why an HMI trend graph will not update every half second.
Checks before you rebuild the screen
- Turn flash off and force both states. If the steady colors land where you set them, the colors are fine and the flash is the only fault.
- Open the object's appearance properties and read its help. If a flash color or flashing-characteristics setting exists for that object, set it and stop. If the list ends at an on/off flash check box, move to the PLC bit.
- If you already tried visibility switching, trend the PLC bit for a minute. Even transitions at the expected period confirm the source. The wobble then lives in the redraw, and the fix is one object driven by one tag, not two objects switched by visibility.
The fix: toggle the two state colors from a PLC bit
- Save a copy of the HMI project before touching the screen.
- Pick the blink source in the PLC. Many PLC families provide a 1-second system bit; use it. If yours has none, build one: a self-resetting timer with a 500 ms preset, whose done bit toggles the blink bit and restarts the timer. That gives one full color cycle per second.
- Clear the object's flash setting, the same appearance property you set to make it blink.
- Bind the object's state tag to the fault condition AND the blink bit, so it swaps colors only while the condition stands. Gating an object on a timer done bit is the same technique used to gate HMI button visibility on a PLC timer done bit.
- Assign your two colors to the two states and keep the text label on the object. A flashing pair of colors must not be the only carrier of the meaning: color vision varies between operators, and the label keeps the message readable in every state.
- Download through your normal change process, then watch both states and both transitions under normal communications. Each color should hold about 0.5 s on the screen.
If the panel hangs off a serial link, the poll interval paces the updates, and the same interval decides whether dropped PLC-triggered messages on a serial HMI panel appear. Budget one poll interval of slack per transition when you judge the visible rate.
Example: an E-stop annunciator at 1 second
A machine needs its E-stop message to flash red and yellow while the E-stop circuit is open, and hold steady red once the operator acknowledges it.
- The PLC timer has a 500 ms preset. Its done bit toggles the blink bit every 0.5 s, so the full cycle is 0.5 s + 0.5 s = 1.0 s: red for 0.5 s, yellow for 0.5 s.
- The driver updates the annunciator tag every 200 ms. Each displayed color therefore lasts between 0.5 s - 0.2 s = 0.3 s and 0.5 s + 0.2 s = 0.7 s, still clearly a flash.
- 60 s / 1.0 s per cycle = 30 color cycles per minute, and a 1-second cycle is 1 flash per second, well under the 3 flashes per second limit the Web Content Accessibility Guidelines set for photosensitive risk.
Result: the message flashes red and yellow with no blue anywhere, the phase never drifts because one tag drives one object, and every visible transition lands within 200 ms of the PLC's own.
Which method to use where
- Flash color property in the editor: use it when the help for your exact object lists one. Least logic, and the PLC stays out of it.
- PLC blink bit on one object: the default. Colors and rate both come from your project, and the phase holds because one tag drives one object.
- Two overlapping objects with a visibility bit: reserve it for objects that cannot take a state tag. Expect the on-screen rate to wobble, because the redraw and the timer run on separate clocks.
Recommendation: Leave the built-in flash off and drive the object's two state colors from a PLC blink bit: the 1-second system bit if the processor provides one, otherwise a self-resetting 500 ms timer. Use the editor's flash color property only when the help for that exact object lists one, and prefer single-object state swapping over two overlapping objects with visibility switching wherever the object can take a state tag.
Questions
Is the blue blink color random?
No. The runtime pairs your chosen state color with a second shade it picks: red has been seen flashing to dark blue and yellow to light blue on the same screen. Because the alternate shade changes with the base color, it looks arbitrary, but no setting reaches it. Treat the pair as fixed for that object type and swap the states from a PLC bit when the colors matter.
What blink rate should I use for a flashing alarm color?
A 1-second cycle with 0.5 s per color is the common choice, and most PLC families reach it with a 1-second system bit or a self-resetting 500 ms timer. Keep the cycle at or below 3 flashes per second, the limit the Web Content Accessibility Guidelines set for photosensitive risk; a 1-second cycle is 1 flash per second and passes with margin.
Does this work for buttons too, or only indicator lights?
Any object that draws two discrete state colors can take its state tag from the blink bit: indicator lights, text objects and pushbuttons. Gate the bit with the fault condition so the object returns to its normal color when the condition clears, and switch to a steady fault color once the operator acknowledges. On a serial link, expect each transition to land up to one poll interval late.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.