简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
OwenBaker0486 · 2026年2月3日 06:19 UTC
Our teaching example had both ends clearing the same flag. Looked fine until the app was delayed. We gave each end its own output and wrote down the return-to-idle exchange before changing either program.
2分A longer pulse might hide this for a while, but which program would you blame when the next delay is longer?
19分That is exactly the argument here, David, because one example calls it a pulse and the other waits for a level that the PLC has already removed
0分Choose one protocol. Mixing examples leaves both ends waiting for events the other never promised.
10分Who teaches the restart case? I'd want that in the exercise too. Students will close the app at the least convenient moment.
13分Jasper, that was our missing page. We had beautiful arrows for success and nothing for a job interrupted halfway through. Tutor had to decide what happened, not just make the arrows start again.
5分I have drawn PLC-owned request and application-owned acknowledgement, with the request held until the matching acknowledgement, then each owner clearing its own signal in order
9分What stops an old acknowledgement satisfying a new request?
25分Kai's point is why I dislike diagrams with only high and low lines and no job identity, though you still have to specify the sequence even with an identity.
18分And please don't label acknowledgement 'finished'. Receipt and finished work are very different things for the person waiting with the next housing.
21分The label actually was 'done', Jasper, although the app raises it on receipt, so that is one small bit of confusion found already
11分I'd rename it before the lesson. You can teach a complicated exchange, but teaching people to ignore what the label says is a pain.
6分Renamed to request accepted on the draft, with a separate completion result, and Kai's stale-acknowledgement case is on the test list
5分Also reject a completion carrying the wrong job identity.
17分Do you need a queue at all, Owen, or can this exercise permit only one outstanding job?
11分Only one, which is enough for passing a housing through the exercise, and a second request should get a clear busy response instead of disappearing
17分We tested ours without motion first. Delayed the receiver, repeated a request, and restarted it while an acknowledgement was outstanding. The repeated request was the embarrassing one: our first version started a second job after we'd already accepted the first. Making the job identity explicit helped us say which repeat was a duplicate and which was actually new work. It also gave the tutor something better than 'don't press it twice'.
12分How did your delayed-receiver test go, Owen?
14分The revised simulator retained the request through a delayed poll and accepted it once, then our duplicate and wrong-identity tests stayed out of the execution path; restart now reports an interrupted job for tutor review
12分That is a much better lesson than making the pulse longer and hoping nobody notices.
20分此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .