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

Our FR5 inspection request can vanish between observations

HarishArcher0402 · 2026年8月15日 05:33 UTC

回复讨论
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 条回复

JO
JoAllen0331

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
AN
AnikaAli0247

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
NI
NinaBennett0762

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

4
OL
OliverAbbott0015

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
JO
JoAllen0331

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
HA
HarishArcher0402

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
AN
AnikaAli0247

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

21
HA
HarishArcher0402

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
NI
NinaBennett0762

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

20
JO
JoAllen0331

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
HA
HarishArcher0402

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
OL
OliverAbbott0015

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
HA
HarishArcher0402

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

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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