简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

What is missing from my FR10 sleeve-unloading video?

CarlaBennett0749 · 2026年8月15日 08:23 UTC

回复讨论
CA
CarlaBennett0749
Nineteen days into our intermittent FR10 unloading ticket. Alibaba seller wants more than my phone video. Which evidence should connect a particular stop to the bench job?

19 条回复

RA
RachelAllen0348

Can you read the displayed message and active step for one occurrence? Link those to its time and installed configuration, marking anything the video cannot establish instead of filling it in from memory

10
KA
KarenCasey

Keep the original clip as well as any stills. A crop may make the text legible while losing the part position that gives it context.

20
BE
BenBrown0892

What happened immediately before it stopped? I'd want the ordinary loading sequence in the account, not just ten seconds of the arm waiting after everyone has walked over.

5
CA
CarlaBennett0749

Video starts after the stop. Text is unreadable. I have the job revision, but no reliable occurrence time.

10
OM
OmarChan1100

Then don't ask operators to remember exact wording. Give them a short capture list for the next occurrence.

18
HU
HugoBriggs

Keep capture within the existing safe operating arrangements; nobody should provoke the stop or reach in for a better picture.

0
AN
AnikaArcher0421

Ask support for the supported history export and how its time is represented. A log may still be useful, but without a trustworthy link I would not pick the entry nearest a guessed video time and call it this stop.

12
AA
AaronBaker0436

Send the installed job revision with that request. A supplier looking at a different revision may explain a step your application doesn't actually use.

14
CA
CarlaBennett0749

New occurrence captured yesterday. Message names a receiving-fixture availability wait. Time and history agree; support has both with our installed revision.

-3
LE
LeoAdams0101

Does the receiving fixture owner agree what that availability means in this version? A clear message is useful, but its name can still hide a disagreement.

14
NA
NathanBennett0721

I'd bring both teams into that answer. On a bench setup the fixture signal could be perfectly real while the application is looking at the wrong source (or expecting it at the wrong stage). Neither is established just by the wait name.

12
BE
BethBarnes0585

Ask for an actual technical reviewer as well. You've now supplied an identifiable event; another sales acknowledgement won't tell you whether they examined the installed mapping.

20
BE
BenBrown0892

Nathan's distinction matters. Don't order a sensor because the screenshot contains the word fixture. What has the technician compared so far?

5
CA
CarlaBennett0749

Technician found our installed job reads the previous fixture mapping. The current receiving interface uses another documented source. Both teams confirmed the mismatch today.

10
RA
RachelAllen0348

Keep the old and corrected mappings with that finding. The responsible team still needs to review the correction and its checks before the application is returned to use

0
CA
CarlaBennett0749

Correction reviewed and applied by the integrator. Supervised checks of available, unavailable and interrupted exchange matched the agreed ordinary interface. No recurrence in those checks. Old video remains unclassified.

19
AN
AnikaArcher0421

That is stronger than a general report that the robot seems happier. Keep the unavailable case in the maintenance test record; the application must still wait when the fixture genuinely cannot receive the sleeve.

9
OM
OmarChan1100

Who now tells the next shift which revision was checked?

11
CA
CarlaBennett0749

Shift supervisor has the revised handover and check record. Thanks Aaron for asking about the installed revision; that comparison found the mismatch.

14

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。