The request exists in the trace and nowhere else

RachelArcher0435 · 25 Apr 2025, 03:25 UTC

Closed
RA
RachelArcher0435
Our UR5e bracket-check application misses some PLC request pulses. The trace shows them. The application does not. A useful distinction from the claim that it randomly refuses work. I am reviewing the ordinary job interface, separate from our engineered safety controls. There is no agreed signal owner or clearing sequence. I think that omission needs fixing before we debate polling intervals.

6 replies

HA
HarishBell0663
Replying to RachelArcher0435

Who writes the request at present? On our old line, both sides could clear a bit and each team swore the other one owned it. Very efficient arrangement for keeping a meeting going.

18 points
RA
RachelArcher0435
Replying to HarishBell0663

PLC sets and clears the pulse. The application also clears the shared request field after acknowledgement. Nobody had documented that second writer. Your meeting sounds familiar.

7 points
HA
HarishBell0663
Replying to RachelArcher0435

Can both teams walk one job through on paper and name the writer at each step? Include what happens when acknowledgement never arrives. Otherwise you'll agree the happy sequence and discover the disagreement again on the first interruption.

11 points
HA
HazelAli0223
Replying to HarishBell0663

What tells the application that a held request belongs to a new job?

-1 points
HA
HarishBell0663
Replying to HazelAli0223

That belongs in the same walkthrough. A held request is easier to observe, but a reconnect can bring it back looking new unless the job identity and recovery rules say otherwise.

8 points
RA
RachelArcher0435
Replying to HarishBell0663

The draft now gives each field one writer and links request acceptance to a job identifier. Timeout and reconnect remain under review. No code changed yet; at least we have something precise to disagree about.

6 points

Discussion closed

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