简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

FR10 inspection receipt with two proposed owners

OscarBennett0706 · 2026年3月26日 18:38 UTC

回复讨论
OS
OscarBennett0706
Our plated-sample inspection proposal has the PLC pulsing an ordinary request which the application sometimes misses. One contractor wants the PLC to clear the receipt as well; the application author says it belongs to them. These are not safety signals. Can we settle ownership with an offline sequence before buying more integration time?

18 条回复

AN
AnilBaker0462

What actually clears the receipt in the version you have?

20
OL
OliverAbbott0015

A longer pulse might make your demonstration look calmer without settling the disagreement, particularly if either side restarts while the other still remembers the sample.

23
OS
OscarBennett0706

The application clears it on its next inspection. The contractor's proposed PLC change would also clear it. Neither document describes a restart.

7
FE
FelixBaker0458

Two writers for one state is a poor starting point. Agree the sequence first. Include a new request arriving while the old receipt is still there.

11
CH
ChloeCarter1005

I had a handover where both teams said their bit was only a mirror, so a table naming the actual writer of each value saved more time than another screenshot.

19
OS
OscarBennett0706

I have asked both authors to fill in that table. The application author also says received means accepted for inspection, not inspection finished.

15
AN
AnilBaker0462

Does the operator display make that distinction?

21
OL
OliverAbbott0015

Felix, a retained receipt can be useful if its identity is clear; I would not insist that every receipt vanish immediately just to make the display tidy.

8
FE
FelixBaker0458

I didn't ask for immediate clearing. I asked what happens when the next request meets it. Retaining a receipt with no matching rule is the problem here.

9
OS
OscarBennett0706

Anil, the display says received, with finished separate. Both authors have now agreed that the PLC owns request and the application owns receipt. Their draft matches an attempt, withdraws that request after receipt, then has the application clear its receipt when it sees the withdrawal.

5
AN
AnilBaker0462

And what prevents a new request being issued before that clearing is observed?

11
CH
ChloeCarter1005

Put that transition into the same drawing, Oscar; otherwise the two authors can each assume the other one supplies the wait.

16
OS
OscarBennett0706

The PLC author has added that wait. We are using the diagram to build the offline cases, including a receipt that arrives after timeout.

8
OL
OliverAbbott0015

For the timeout case, keep the uncertain attempt available to reconcile. A fresh identity should not quietly turn an unconfirmed physical sample into a different sample that everybody assumes is untouched.

13
FE
FelixBaker0458

Has either restart case been run yet?

13
OS
OscarBennett0706

Application restart was run. It wrongly cleared the outstanding receipt before reading the retained request. PLC restart is still waiting its turn.

7
AN
AnilBaker0462

That is worth finding before commissioning. Who is defining how the uncertain sample is reconciled after that restart?

19
OS
OscarBennett0706

Our integration lead and laboratory lead own that response together. They have not finished it. I have authorised the next offline test work against the agreed sequence, not an installed change; at least the quote now names what we need answered.

17

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。