Our request is gone before the application notices

Both owners say the other one clears it. Helpful.

Bring the code to the meeting.

Yes. Show them that occurrence.

Trace found. PLC clears on its timer; app clears after acknowledgement. Two writers confirmed.

Now agree one writer per field, plus the conditions for changing it. Put the agreement beside the signal list.

Does the application distinguish a newly issued job from a request still present after reconnect? Holding the request will help it see the value, but the job identity may still need attention.

No. It calls every first high reading a new job.

That needs a recovery rule too. The operator should not have to infer whether work was accepted before the connection went away. A retained job reference and a visible unresolved state are possibilities for the interface review.

We had a class exercise that looked perfect until we closed and reopened the monitor. It immediately submitted the same job twice. The students thought they had broken the robot. They had exposed a missing case in my example. Walk through a request missed entirely, a request accepted before disconnect and a result returned while the application is away. Ask what each side knows at every step. That is a useful lesson even before any code changes, and it gives whoever supports the cell a fighting chance of explaining a stuck screen.

Ouch. Yes, add those cases.

Added to the review. Nobody is changing the polling interval as the whole fix now.

Who will own the remaining unresolved-job decision during a shift? The interface can display uncertainty correctly and still leave production waiting if no one is assigned to handle it.

Shift lead, with controls backup. Draft agreed; still needs the joint tests.

Put those names on the handover. Otherwise it's back to calling whoever wrote the first version.