I cannot decide who should clear this job request

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

Choose one protocol. Mixing examples leaves both ends waiting for events the other never promised.

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.

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

What stops an old acknowledgement satisfying a new request?

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.

And please don't label acknowledgement 'finished'. Receipt and finished work are very different things for the person waiting with the next housing.

The label actually was 'done', Jasper, although the app raises it on receipt, so that is one small bit of confusion found already

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.

Renamed to request accepted on the draft, with a separate completion result, and Kai's stale-acknowledgement case is on the test list

Also reject a completion carrying the wrong job identity.

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

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

How did your delayed-receiver test go, Owen?

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

That is a much better lesson than making the pulse longer and hoping nobody notices.