Diagnose factory screen update delay

Separate control delay from screen delay

Start with two questions: when does the main controller receive the new input state, and when does that state become visible on the sign? These are different measurements.

If the main controller receives the input late, investigate the remote input and controller link. If its input value changes promptly but the sign stays unchanged, investigate the path from the controller to the display application.

The andon board guide covers where a small sign fits. This diagnosis is narrower: locating elapsed time between a source event and its visible indication.

Map the actual installation rather than relying on connector labels. Record the protocol, communication settings, data owner, and polling device for every link. A serial connector alone does not identify the protocol.

Keep the sign outside the machine's control path. Our shop-floor displays support offline playback or your own Android app, but controller integration timing must be assessed separately. For help defining the signage scope, send the timing requirements.

Read the symptoms

Use the pattern of the delay to decide which measurement comes next:

• The main controller value and sign are both late: investigate upstream acquisition and controller-to-controller transfer before changing display settings.
• The main controller changes promptly, but the sign changes at regular intervals: check the application's polling and redraw schedules.
• Several values appear together in a burst: check grouped reads, queued requests, and whether the application waits for a complete update before drawing.
• Delay grows as more devices or values are added: inspect bus utilization, polling order, and transaction count.
• Delay varies widely and communication error counters rise: investigate retries, timeouts, and the physical link rather than assuming the baud rate is too low.
• The application receives data promptly, but the visible state is late: inspect application processing and screen updates.
• A brief input change never appears: check input filtering, sampling intervals, and whether the event is latched in the controller. A screen that shows current state may never display a transition that occurs between reads.

These patterns are clues, not proof. Confirm each one with measurements from the relevant stage.

Record a baseline safely

Use documented diagnostics and an approved maintenance procedure. Do not force machine outputs, bypass interlocks, or alter safety logic to create a convenient test signal.

1. Choose an observable event. Use an approved diagnostic signal or a repeatable normal state change that does not create hazardous motion.
2. Identify the same event at each stage. A diagnostic event counter can help distinguish consecutive transitions if the controller and application support one.
3. Record the source and destination values. Note the remote controller value, main controller value, application receipt, and visible change wherever the available tools allow.
4. Check the time basis. Do not subtract timestamps from devices with unknown clock offsets. Use a common time reference or measure intervals within one diagnostic tool.
5. Repeat the observation. Capture transitions at different points in the polling cycle, both under light communication load and representative operating load.
6. Save the configuration. Record polling periods, baud rates, transaction sizes, timeouts, error counters, and relevant application settings before changing anything.

A video recording of an approved source indicator and the screen in the same view can help measure total visible delay. Its resolution is limited by the recording frame interval, and it cannot separate the internal stages by itself.

Avoid excessive diagnostic polling. Adding reads can change the very communication load you are trying to measure.

Check polling before increasing baud rate

A polling interval can dominate the result even when each message travels quickly. With a 500 ms polling interval, an event arriving just after a poll may wait nearly 500 ms for the next one. For events distributed uniformly through that interval, the average waiting time is about 250 ms, before transaction and processing time.

Check for separate schedules at different stages. A remote controller might transfer data periodically, while the display application reads the main controller on another schedule. Their waiting times can accumulate.

Serial transmission has a different limit. For an illustrative asynchronous serial format with one start bit, eight data bits, no parity, and one stop bit, each byte occupies 10 transmitted bits. A total of 100 transmitted bytes therefore takes approximately:

• 104 ms at 9,600 bits per second.
• 52 ms at 19,200 bits per second.

Those figures cover transmission time only. Requests, responses, protocol overhead, turnaround gaps, processing, retries, and waiting for bus access can add time. Other serial formats use a different number of bits per byte.

Count the whole transaction, not just the status payload. Many small reads can consume more time than a documented grouped read because each transaction repeats overhead.

Raise the baud rate only when every participating device on that segment supports the setting and the installation meets the manufacturer's communication requirements. A faster setting that increases errors can make the useful update time worse.

Distinguish data updates from screen refresh

Application polling, application redraw, and panel refresh are separate operations. A panel cannot display a new state until the application has received and rendered it. A higher panel refresh rate does not fix an application that requests controller data infrequently.

Compare the application's receipt timestamp with its state-change or redraw timestamp, if documented diagnostics expose them. Check whether the application:

• Queues new values behind other work.
• Applies a deliberate update interval or debounce period.
• Waits for several values before drawing the page.
• Uses an animation that delays the final readable state.

The included offline signage player plays images and video from microSD or USB. For controller-driven status, identify the separate application or integration that reads controller data; do not assume file playback provides that connection.

If the installation actually displays exported status images rather than live values, include image generation, file transfer, and playlist presentation in the timing map. The image and video preparation guide covers media preparation, not controller-to-screen response timing. A file-based show is the wrong choice when a machine function depends on a specified response time.

Change the measured bottleneck

Choose the smallest documented change that addresses the measured delay:

• Long polling wait: review the supported polling interval and controller communication capacity. Shorter intervals add traffic and processing load.
• Excessive transaction count: consider documented grouped reads where values can be read consistently together.
• High serial transmission time: review supported baud rates and segment configuration before considering replacement hardware.
• Retries or timeouts: correct the documented communication fault first. Do not simply shorten timeouts until valid replies are rejected.
• Late application drawing: reduce unnecessary application work or adjust its supported update settings.
• A heavily loaded network link: measure utilization, queues, and endpoint response time before replacing the network.

Moving from a serial link to Ethernet is an architectural change, not an automatic cure. It may reduce transfer time while leaving controller scheduling and application polling unchanged. Confirm protocol support, data consistency, configuration requirements, and application compatibility first.

Back up the configuration, make one change during an approved maintenance window, and retain a rollback path. Do not change machine safety functions to improve a sign's apparent response.

Check the result against the requirement

Repeat the baseline observations with the same event, measurement method, and representative load. Compare typical delay, the longest observed delay, and communication error counts. Do not report only the fastest transition.

Verify that both directions of a state change appear correctly. If short events matter, confirm that the controller records them in a documented way rather than relying on the display to catch each transition between polls.

For a custom status application, define how old data is identified and how loss of communication is indicated. A stale value should not look like a newly confirmed machine state. Treat this as an integration requirement, not an assumed feature of the display.

Finally, compare the measured result with the actual requirement. Measurements can show whether a change improved the installation; they do not establish an upper bound on response time. If the task needs a bounded machine response, use a control architecture specified for that requirement and keep the signage informational.

Questions