The FR10 pauses only after lunch, apparently

OwenBrooks0834 · 16 Mar 2025, 17:49 UTC

Closed
OW
OwenBrooks0834
Our FR10 sleeve-unloading cell has paused on three afternoon shifts. The seller from Alibaba wants more evidence than my phone clip. Everyone is now saying after lunch as though sandwiches are a control signal. I have three times written down, but no confirmed pattern yet.

18 replies

AN
AnilAllen0288
Replying to OwenBrooks0834

Three afternoons aren't a diagnosis. What message or active step did each pause show?

24points
OW
OwenBrooks0834
Replying to AnilAllen0288

Only one has a screen photo: waiting for downstream ready. The other two notes just say stopped. I have asked support to keep those separate for now.

0points
AN
AnilAllen0288
Replying to OwenBrooks0834

Good. Start with the one you can actually identify.

16points
OW
OwenBrooks0834
Replying to AnilAllen0288

That occurrence has a matching event export too. Sent it with program version and the screen photo. Support asks whether the downstream tray station was running.

5points
AN
AnilAllen0288
Replying to OwenBrooks0834

Was it?

11points
IM
ImranAllen0305
Replying to OwenBrooks0834

Check the downstream station's own record at the same time, allowing for any clock difference. It may have been running generally but unable to accept the next part. The distinction would help support identify what downstream ready actually means here.

16points
OW
OwenBrooks0834
Replying to ImranAllen0305

Tray station was waiting for an empty rack on that occasion. Operator had left to fetch one. That's in its shift note, so the robot pause may have been expected.

4points
AN
AnilAllen0288
Replying to OwenBrooks0834

May have been. Ask support to confirm the wait condition before closing that occurrence.

11points
NA
NaomiBrown0941
Replying to ImranAllen0305

Our tray station log clock was seven minutes off the robot's, so match the sequence as well as the displayed time if you can

14points
AN
AnilAllen0288
Replying to NaomiBrown0941

Worth checking. Otherwise you'll attach the wrong rack shortage to the right robot pause.

13points
LU
LucaBarnes0526
Replying to OwenBrooks0834

I'm interested in what the other two turn out to be, because our supposed afternoon fault was two unrelated waits that happened to share a lunch break.

18points
AN
AnilAllen0288
Replying to OwenBrooks0834

Any new occurrence with a readable message?

9points
OW
OwenBrooks0834
Replying to AnilAllen0288

One this week. Different step: waiting for fixture release. Support confirmed the earlier downstream pause was expected. We now have a separate ticket entry for the fixture wait, with its own timestamp and photo.

9points
AN
AnilAllen0288
Replying to OwenBrooks0834

So after lunch has retired. Did they identify which fixture signal was absent?

13points
IM
ImranAllen0305
Replying to OwenBrooks0834

Have maintenance capture the fixture's physical state alongside the available input display when it happens. Support can then compare what the fixture did with what the program saw, without treating either observation as the whole explanation.

22points
OW
OwenBrooks0834
Replying to AnilAllen0288

They identified the release confirmation. Maintenance is investigating; we have not established whether the missing confirmation reflects delayed movement or a sensing problem. No settings changed on a guess.

15points
OW
OwenBrooks0834
Replying to LucaBarnes0526

I renamed our shift log entry to the actual wait step. Afternoon fault was sending everyone in circles. One pause explained, one still under investigation, two old notes still too vague to classify.

7points
AN
AnilAllen0288
Replying to OwenBrooks0834

That's useful progress, even without a single grand cause for all four notes.

8points

Discussion closed

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