Our FR5 inspection request can vanish between observations

HarishArcher0402 · 15 Aug 2026, 05:33 UTC

Reply to discussion
HA
HarishArcher0402
The application sometimes misses the PLC's short inspection request. I'm reviewing the ordinary job interface for our FR5 bracket-checking cell. Request ownership and clearing rules are unclear. What should the two teams agree before changing it? Safety controls are separate from this interface.

13 replies

JO
JoAllen0331
Replying to HarishArcher0402

Write a state table with one writer for each signal. It should say what request and acknowledgement mean, and what observation permits each owner to clear its output.

17 points
AN
AnikaAli0247
Replying to JoAllen0331

On an inherited fixture I found two teams both clearing the same ordinary job flag. Each thought they were cleaning up after the other. Have them walk one exchange together before deciding the pulse is the only defect.

15 points
NI
NinaBennett0762
Replying to JoAllen0331

Also record whether acknowledgement means received or finished. Those cannot share an unexplained tick on the screen.

4 points
OL
OliverAbbott0015
Replying to JoAllen0331

Holding the request until acknowledgement might answer the missed observation, but it introduces a retained state to reconcile at restart. I would not call the change complete with only the normal exchange documented.

10 points
JO
JoAllen0331
Replying to OliverAbbott0015

Agreed. Include initial connection, either side restarting, timeout and an acknowledgement that remains present. I was describing the table, not approving a specific implementation.

6 points
HA
HarishArcher0402
Replying to NinaBennett0762

The walkthrough found both problems. The PLC pulses the request. Application acknowledgement means received, but our display labels it done. The controls owners are rewriting the ordinary exchange with separate receipt and result states.

9 points
AN
AnikaAli0247
Replying to HarishArcher0402

Who will maintain that table after somebody adds another inspection variant? Put it with the revision-controlled application handover.

21 points
HA
HarishArcher0402
Replying to AnikaAli0247

Controls lead owns the shared table; both teams review changes. The misleading done label is corrected in the test application. We haven't changed the cell exchange yet.

18 points
NI
NinaBennett0762
Replying to HarishArcher0402

Does the draft stop a stale acknowledgement being accepted as receipt of the next request?

20 points
JO
JoAllen0331
Replying to NinaBennett0762

That belongs in the test set with the delayed receiver. A longer visible request is not enough if old response state can satisfy the next exchange. Show which current request a response belongs to under the agreed contract.

7 points
HA
HarishArcher0402
Replying to JoAllen0331

Both teams approved the revised contract. In the offline test, delaying the receiver no longer loses the held request. Replaying the previous acknowledgement cannot complete the next exchange; a restart leaves an unfinished exchange for reconciliation. We also checked each normal clear transition against the table.

22 points
OL
OliverAbbott0015
Replying to HarishArcher0402

Useful evidence for the application contract. Keep those offline results distinct from site commissioning, especially with the separately engineered safety system outside this test.

16 points
HA
HarishArcher0402
Replying to OliverAbbott0015

Yes. The ownership dispute and offline defect are closed. Cell deployment is a separate reviewed job, with these test cases in its handover. Thanks Anika, the joint walkthrough found a second issue we would have missed by only stretching the pulse.

4 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.