The PLC request for a housing check is so brief that our application sometimes sees nothing. The tutor then presses request again, which is becoming part of the lesson. I am not happy teaching that.
This is the ordinary job exchange; the cell's safety functions are separate. Both developers say their side works, but neither document says who retains the request, acknowledges it or clears it. What should we agree before we change the teaching material?
Our training display once missed a short request too. Seeing a pulse in the PLC trace did not mean the receiving application had seen it. Both sides need one agreed exchange.
Put the signal owners, meanings and clearing conditions in one table. Include how a particular inspection attempt is identified. The lesson should not depend on which developer explains it that day.
A table is necessary, David, but get both owners through the sequence together as well. Two programs can implement the same words differently, particularly a word as helpful as done.
Separate receipt, work in progress and result in that walkthrough. Acknowledging the request is not the same event as completing the housing check, however tempting a single green box might be.
Our trace shows the request disappearing before the application polls. The developers have agreed that part now. They disagree about whether received should clear it immediately or wait for the result, so Leo's distinction is timely.
We treated a timeout as cancellation in an early fleet interface and then found the original work still running, so I would put timeout beside interruption in the walkthrough before anybody adds another retry button.
For handover, I would ask the tutor to explain what the operator knows at each stage. Request sent, receipt confirmed and result available need different explanations. An uncertain outcome needs a named route for reconciliation, not a cheerful suggestion to ask again.
Reserve time for someone who did not build it to try that explanation, Luis. I would include it in the training allowance now, rather than wait until the interface is declared finished and everyone has left.
Our most useful handover session was the one where the instructor stopped at a screen nobody else thought was confusing. Mei, keep your tutor in the review. Repeated button pressing is telling you where the missing explanation hurts.
Mina, did your timeout case have an attempt identity retained on both sides? Without that, even a good recovery screen can be short of something to reconcile.
Not initially, Leo; we added a retained reference and an explicit uncertain state, but that did not recover the outcomes of the earlier requests for which the evidence was already missing.
Thanks, Luis and Maya. We have booked the tutor walkthrough as part of the work. The draft now separates receipt from result and includes interrupted requests, but we haven't agreed how the receiver retains its accepted work after restart.
That retention question needs an implementation answer from the receiver's owner, not just a box labelled remembered on the teaching slide. Beth's question is still doing useful work here.
Receiver's owner is checking that storage boundary. We are withholding the new exercise until the normal and interrupted exchanges are demonstrated against the agreement. The old keep-pressing advice has been removed already.
Keep the unresolved case in the exercise review. A working normal request is useful progress, but the tutor still needs to know what to say when the result cannot be established.