Why does our FR10 lesson say press again when the request disappears?

FionaAli0238 · 30 Oct 2025, 09:42 UTC

Closed
FI
FionaAli0238
I watched a student follow our inspection worksheet exactly: press request, wait for a blank status box, press it again. The worksheet actually tells them to do that. Our ordinary job request is a short PLC pulse and the application sometimes misses it, so we've apparently taught the workaround instead of describing the handshake. I want the revised lesson and interface to agree. Where would you begin?

15 replies

SA
SamCarter1029
Replying to FionaAli0238

Compare the request and app-read times before changing the lesson around an assumed cause.

16 points
NI
NinaAbbott0066
Replying to FionaAli0238

I'd withdraw that press-again instruction now. Not replace it with another guess, just stop presenting it as the intended method. Is the supplier aware that's what your students are being taught?

17 points
FI
FionaAli0238
Replying to NinaAbbott0066

Yes, Nina. I've taken that worksheet out of the session and sent the example to our support contact. Sam, the trace shows a request rising and falling between application reads. It isn't just the student missing a screen change.

4 points
TO
TobyBrooks0840
Replying to FionaAli0238

What does the blank box mean? Nothing requested, still waiting, or no connection?

-4 points
SA
SamCarter1029
Replying to TobyBrooks0840

Those need separate meanings. A longer pulse alone won't explain the blank box.

17 points
IS
IsabelAdams0126
Replying to TobyBrooks0840

I would sketch the displays on paper before asking for new screens. Give someone the pending request and lost-connection examples without the explanation underneath. If both look idle, the new wording has not helped much.

11 points
NI
NinaAbbott0066
Replying to SamCarter1029

Sam, nobody's asking for a longer pulse here. The lesson needs a response a tutor can explain, including what to do when no answer comes back. Otherwise the next workaround will be somebody's handwritten note.

20 points
SA
SamCarter1029
Replying to NinaAbbott0066

Agreed. I was warning against the obvious patch, not saying Fiona requested it.

20 points
FI
FionaAli0238
Replying to IsabelAdams0126

Toby, blank currently covers all three. Isabel, paper screens sound useful; our tutors can argue over those without waiting for the programmer. The supplier is proposing a held request with a matching acknowledgement rather than a pulse.

0 points
TO
TobyBrooks0840
Replying to FionaAli0238

Include leaving the page and coming back (easy one to miss in a lesson).

0 points
IS
IsabelAdams0126
Replying to TobyBrooks0840

That is worth doing. We found a request could remain active while a reopened page looked unused. Fiona, make the restored screen part of the example, not just the first press.

25 points
NI
NinaAbbott0066
Replying to FionaAli0238

And who answers the tutor's call if it stays waiting? A working explanation needs a person at the other end too. Doesn't have to be the programmer for every question.

22 points
FI
FionaAli0238
Replying to IsabelAdams0126

The paper exercise was revealing. One tutor read waiting as permission to press again; another thought it meant inspection had started. We've split request pending from job accepted in the proposed display. Thanks Isabel, that caught something our trace couldn't tell us.

6 points
FI
FionaAli0238
Replying to NinaAbbott0066

Nina, our lab technician is first contact, with the supplier route behind that. Toby and Isabel, page return is on the test list. No revised software back yet, so the old worksheet stays out.

12 points
SA
SamCarter1029
Replying to FionaAli0238

Keep the missed-request trace for testing the revision. The paper result and software result answer different questions.

18 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .