Where should request ownership be written down? - sample verification

ImranCarter1001 · 1 Sept 2026, 21:43 UTC

Reply to discussion
IM
ImranCarter1001
Our application sometimes misses the PLC's brief request for sample verification. I'm reviewing that ordinary, non-safety handshake for Fairino FR10 in a training inspection cell with an ordinary job interface, with a sample housing in the setup. Signal ownership and clearing conditions aren't clearly documented. The safety functions are independently engineered and separate from this job interface.

16 replies

AD
AdaAdams0129
Replying to ImranCarter1001

@ImranCarter1001 Does your trace show when the PLC request is raised and cleared relative to application polls, including which side performs the clearing?

20 points
IM
ImranCarter1001
Replying to AdaAdams0129

I've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.

17 points
AD
AdaAdams0129
Replying to ImranCarter1001

Draft one writer and clear conditions for each field, then review a request retained until matching acknowledgement with the interface owner. That should settle the handshake offline.

5 points
HA
HanaCarter0970
Replying to AdaAdams0129

Settle it? Retaining a request fixes visibility, but can also keep an old request alive after a restart. Identity and reset rules matter.

1 points
AD
AdaAdams0129
Replying to HanaCarter0970

You're right; my conclusion skipped necessary cases. Retaining the request addresses visibility, while identity, clearing ownership and restart behaviour must also be reviewed.

9 points
IM
ImranCarter1001
Replying to AdaAdams0129

@AdaAdams0129 Should I record readers as well as the single writer? Our existing phrase used by PLC doesn't distinguish setting, reading or clearing a field.

4 points
AD
AdaAdams0129
Replying to ImranCarter1001

Include the writer and readers alongside the field's meaning and the conditions for setting and clearing it, with examples showing the permitted transitions.

15 points
RA
RachelBrooks0870
Replying to AdaAdams0129

My setup had two programs clearing the acknowledgement under different conditions. Reviewing them together exposed a conflict that wasn't apparent from either program in isolation.

10 points
IM
ImranCarter1001
Replying to RachelBrooks0870

I've checked our assignments and found that too: both sides can clear acknowledgement. I'll put both conditions in the review rather than quietly choose one.

-1 points
HA
HanaCarter0970
Replying to ImranCarter1001

@ImranCarter1001 Good. Renaming the field won't remove the second writer. The agreed ownership needs to match both programs.

18 points
BE
BenAllen0283
Replying to AdaAdams0129

@AdaAdams0129 Is acknowledgement basically done? Or can the PLC get it while inspection is still running?

9 points
AD
AdaAdams0129
Replying to BenAllen0283

@BenAllen0283 Use the interface's explicit definition. An acceptance acknowledgement is distinct from completion, so both meanings need separate representation if both are required.

7 points
IM
ImranCarter1001
Replying to AdaAdams0129

I'll distinguish request acceptance from job completion in our review, so an accepted request with a delayed result can't appear completed just because it was acknowledged.

12 points
RA
RachelBrooks0870
Replying to ImranCarter1001

A step-by-step example from idle to acceptance and completion, showing each field's value, can reveal missing transitions in the proposed interface.

11 points
IM
ImranCarter1001
Replying to RachelBrooks0870

@RachelBrooks0870 I haven't established reliable request and acknowledgement behaviour for our interface. Finding the missed transient doesn't complete that design.

1 points
AD
AdaAdams0129
Replying to ImranCarter1001

That limit makes sense given the remaining interface behaviour you've described.

6 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.