OwenBaker0486 · 3 Feb 2026, 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 pointsA longer pulse might hide this for a while, but which program would you blame when the next delay is longer?
19 pointsThat 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 pointsChoose one protocol. Mixing examples leaves both ends waiting for events the other never promised.
10 pointsWho teaches the restart case? I'd want that in the exercise too. Students will close the app at the least convenient moment.
13 pointsJasper, 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 pointsI 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 pointsWhat stops an old acknowledgement satisfying a new request?
25 pointsKai'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 pointsAnd please don't label acknowledgement 'finished'. Receipt and finished work are very different things for the person waiting with the next housing.
21 pointsThe label actually was 'done', Jasper, although the app raises it on receipt, so that is one small bit of confusion found already
11 pointsI'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 pointsRenamed to request accepted on the draft, with a separate completion result, and Kai's stale-acknowledgement case is on the test list
5 pointsAlso reject a completion carrying the wrong job identity.
17 pointsDo you need a queue at all, Owen, or can this exercise permit only one outstanding job?
11 pointsOnly 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 pointsWe 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 pointsHow did your delayed-receiver test go, Owen?
14 pointsThe 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 pointsThat is a much better lesson than making the pulse longer and hoping nobody notices.
20 pointsThis discussion is closed to new replies after six months without activity. Last activity: .