Our FR10 sleeve loader pauses. The station monitor sometimes loses its status update too. The seller saw my phone clip and asked us to check the network, which has now become everyone's diagnosis.
I administer the network, so naturally this has landed on my desk. What should I capture to tell whether the failed monitor read belongs to the same event as the physical wait? I am quite prepared for it to be our problem. I would like evidence before the group email awards it to me.
Capture the station's active step and message independently of the monitor, then link those to the monitor's request error and event time. The stationary tool alone won't tell you whether communication failed or the sequence is waiting for a fixture condition.
That is a sensible starting point. Include the software version and what each log's time represents, especially if one records a request starting and another records the error returning.
Found another wrinkle. The monitor log prints its last known fixture status after a failed request. People have been reading that line as a fresh controller response.
Have the monitor maintainer separate the failed request from that retained value. Otherwise your next paired capture will still need somebody to explain which lines represent new observations.
We had a report with correctly named files that still showed different things. The writer knew which value was old and forgot everybody else didn't. Could your report show last successful update time beside the retained status?
Yes. Maintainer is adding that and a clear failed-read entry. The current monitor display is being changed too; it leaves the old status looking current after the error.
That will make the monitor easier to interpret. You still need the station's own evidence for the physical pause, so I would keep that request moving alongside the display repair.
Only reads status. The loader's sequence runs separately. We are checking the communication failure, but I have asked the team to stop assuming that repairing the display will make the arm continue.
Have you managed to capture a new pause from both sides yet? The display bug is useful to fix, but I'm interested in what the station was actually waiting for.
Fiona, did the revised display make it to both shift workstations? We once corrected the developer's view and left the operator shortcut opening the old copy.
New capture shows the station waiting for the receiving nest's confirmation. Monitor had a successful fresh read during that pause. The earlier failed-read occurrence is still separate. Both workstation shortcuts now use the checked display version.
Send that matched occurrence to the seller and ask which confirmation input they want maintenance to inspect. Keep the earlier read failure as its own open issue, with the network evidence you have.
That label confusion is familiar. We had a part status and a request status both called result. Took an operator asking result of what to embarrass the rest of us.
Fiona, any progress on the nest confirmation since the paired capture? I would be interested whether the device or the sequence handling needs attention.
Device identified. Maintenance found a mismatch between the fitted target arrangement and the fixture drawing, now with tooling for review. The monitor read failure hasn't recurred in our logged checks, but we have not explained that earlier occurrence.