HenryAdams0090 · 30 Sept 2025, 08:13 UTC
A line I supported kept stretching a request pulse whenever the laptop got busier. It bought time without settling whether the request had been accepted. I'd define an acknowledged request and its owner instead of chasing a lucky pulse length.
1 pointsHave you captured the request arriving at the application at all, or only watched the PLC bit change?
15 pointsI'd like the screen to distinguish waiting for the application from inspection running. Operators tend to interpret a flashing request indicator as activity, even when nothing has accepted the job.
4 pointsAmy, is an acknowledged request something we'd expect in the original integration scope, or does this become a new charge? I'm not trying to price a bit, just understand what handover should include.
1 pointsMia, only the PLC trace so far. Owen, the screen says running as soon as it sends the request. That's misleading, thanks for pointing it out.
0 pointsThe screen should change, but that does not tell you whether the receiver saw this particular request; the two tests need separate answers.
8 pointsJasper, look at the agreed function rather than counting interface bits. If inspection-cycle coordination was supplied, ask the integrator to show how a request is accepted, completed and recovered after an interruption. I can't settle the commercial scope from here.
3 pointsWe had two suppliers each assume the other wrote the timeout message, so I would put the owner of that screen behaviour beside the owner of the handshake, not leave it in a general handover paragraph.
18 pointsDoes the PLC clear its request on a timer now, or is the application writing that same value too?
15 pointsAnd who gets called when it stays waiting? Make that somebody's job.
11 pointsFor training, waiting needs a reason and an allowed next step. It shouldn't invite people to keep pressing request. I've seen repeated presses turn one unclear inspection into several unclear requests.
3 pointsThe maintainer also needs the interface description kept with the delivered software version. A clear ownership table is useful, but a later replacement laptop can undo the arrangement if its application expects the earlier behaviour.
10 pointsKai, both sides can clear the same request in the current draft. We're removing that shared ownership. The revised design isn't tested yet, and the screen wording is part of it now.
5 pointsGive acceptance its own meaning in that revision. It should identify the request being taken, not merely say the application is connected. A connection can be healthy while the requested inspection has not been accepted.
18 pointsLuis, that helps. I'll ask for a demonstration of those agreed behaviours, with the interruption case included, before arguing about whether an extra column in the interface list is chargeable.
11 pointsJulia, I agree about repeated presses. I'd include an unanswered request in the training walkthrough and ask what people think they should do. That will show whether the revised wording actually helps.
2 pointsThis discussion is closed to new replies after six months without activity. Last activity: .