Why Does the MT8102iP Project Freeze on a Black Screen?

The display goes black, project controls stop responding, and data logging stops. Yet the setup menu still opens from the lower-right arrow. Start there: that split tells you whether the whole panel failed or the HMI project runtime lost execution time.

Confirm which layer is frozen

1. Wait for the black-screen condition without restarting the panel.
2. Press the lower-right arrow used to open the setup menu.
3. Check whether the setup menu appears and responds normally.
4. Check whether project data logging stopped at the same time as the display.

In the reported failure, the setup interface remained available while both graphics and data recording stopped. That points to the project execution path rather than a completely locked panel.

Eliminate the screen saver first

Disable the screen saver and repeat the operating test. This is the quickest branch because a black screen resembles a screen saver that cannot exit.

If the problem returns with the screen saver disabled, stop changing screen-saver settings. That is not the fault. Repeatedly adjusting its timeout or wake behavior wastes time because those settings cannot explain a project freeze that persists after the feature is removed.

Keep the lower-right setup test in the diagnostic routine. It separates a black project display from loss of the complete panel interface and prevents unrelated hardware troubleshooting.

Count and isolate cyclic data transfers

Inspect every cyclic data-transfer object in the project. Record three things: the number of transfers, how often each transfer executes, and which PLC connection each one uses.

Cyclic transfers execute at the same priority as the graphics. A large transfer workload therefore competes directly with screen drawing and touch handling. If a PLC responds slowly, the communication work remains active longer and increases the time denied to graphics. Data logging can stop with the display because it also depends on the project runtime making progress.

1. Create a list of all cyclic transfers and their source and destination connections.
2. Temporarily disable one transfer group at a time.
3. Run the panel long enough to cover the operating conditions that normally produce the freeze.
4. Watch graphics response, touch response, and continuity of logged records.
5. If removing a group prevents the fault, inspect that group for excessive transfer count, scattered addresses, or a slow PLC path.
6. If the fault remains, restore the group and test the next one.

Change one group per test. Disabling everything at once may remove the symptom, but it will not identify whether load volume or one communication path triggers it.

Find the slow PLC path

Test the communication path behind each heavy transfer group. Read the connection status and communication diagnostics available in the project or panel, then compare response behavior while the machine is idle and while PLC traffic is high.

• If one PLC connection becomes slow before the graphics degrade, reduce the work issued through that connection and correct its communication problem.
• If every connection remains responsive but graphics degrade as transfer count rises, the aggregate cyclic workload is the controlling factor.
• If disabling a particular transfer group restores both graphics and logging, move that group out of cyclic data transfer first.

Do not spend the first service visit rebuilding screens or replacing display objects. Those changes do not remove the scheduling conflict between cyclic transfers and graphics. Also avoid increasing traffic by adding diagnostic transfers during the test; use existing status information or test a small group in isolation.

Move transfers into a timed macro

Replace the resolving transfer group with a timed macro. Macro execution has lower priority than graphics, so transfer work no longer competes with the display at the same priority.

For each value, read the source with GetData and write it to the destination with SetData. The following project-specific example transfers one value from one PLC connection to another:

macro_command main()
short Var
GetData(Var, "PLC2_Siemens S7-1200", "MArea-AUT_CMD_BR2", 1)
SetData(Var, "PLC3_Siemens S7-1200", "DB14_HMI2(forno2)_to_PLC3[DB14]-Reg_Ciclo_Generale_PLC2", 1)
end macro_command

The same pattern can move data from PLC to PLC, PLC to HMI, or HMI to PLC. Treat the connection names and addresses above as examples from one project; select the actual source and destination defined in your project.

1. Declare a temporary variable with the data type required by the transferred value.
2. Call GetData for the source.
3. Call SetData for the destination only after the read completes.
4. Repeat the pair for each independent value or block.
5. Configure the macro for timed execution based on the process freshness requirement.
6. Remove or disable the replaced cyclic transfer so the project does not execute both methods.

Reduce instruction count by grouping variables stored at consecutive locations. One GetData/SetData pair can transfer multiple consecutive values by changing the element count. Before grouping, verify address order, data width, and source-to-destination layout; a larger block with mismatched layouts moves the wrong data efficiently.

Do not choose the macro period by guesswork. Determine how stale the destination may become without affecting control, alarms, or operator decisions. Use that requirement as the upper limit, then confirm that the selected rate leaves graphics responsive under the slowest observed PLC communication.

Verify the resolving branch

1. Run the revised project with the screen saver still disabled.
2. Exercise the screens that previously became unresponsive.
3. Operate the PLC connections under the load associated with the original failure.
4. Confirm that touch actions and screen changes remain responsive.
5. Compare each macro destination with its source and confirm that consecutive blocks retain the intended order.
6. Review the data log across the full test and check for gaps.
7. Open the lower-right setup menu during the test, return to the project, and confirm that both interfaces continue operating.

A short bench test is not enough for a random fault. Run beyond the longest interval previously associated with a freeze and include periods when PLC communication is busiest. If the display remains responsive but transferred data becomes stale, shorten the macro period or divide the work into smaller timed groups while monitoring graphic response.

FAQ