FAIRINO Demo Acceptance Test: Evidence to Request Before Buying

Define what this demonstration can prove

Write a brief that names the proposed process, representative parts, tool concept and specific buying questions. A demonstration might establish that the tool can present a part to a fixture, that the intended controller can exchange process signals or that a trained operator can recover an ordinary interruption. These are different claims and need different evidence. Avoid an undifferentiated acceptance box labelled robot works.

State the boundaries of the event. If the supplier uses a mock machine, identify which opening, fixture and timing features it represents. Mark omitted services and process conditions explicitly. FAIRINO's Foreword describes responsibilities around the robot system; use it as a reference when assigning integration ownership. The editorial framework here is to approve only the propositions actually tested, while leaving site installation, completed-cell validation and production performance to their agreed project stages.

References: User Manual 3.8.3: Foreword and important safety description

Freeze the test configuration

Record arm identity, controller identity, software, tool revision, load definition, mounting arrangement and program revision. Include any external computer or PLC used in the demonstration. FAIRINO's C++ Basics documentation provides queries for software, hardware and firmware versions. Ask the supplier to capture the applicable identifiers so that a successful result can be associated with the equipment being offered, rather than an unspecified demonstration platform.

Take setup photographs and attach the layout drawing. Establish a change log before testing: if the demonstrator changes a tool, coordinate, fixture or program, note why and which results need repeating. Small edits can be sensible engineering, but they alter the evidence. Keep preliminary troubleshooting separate from the agreed acceptance run, and record whether the final tested configuration is included in the quotation or requires additional development and equipment.

References: C++ SDK: Basics and version queries

Choose inputs that expose the buying uncertainty

Bring parts that represent the variation relevant to the proposed task: different approved sizes, surface conditions, presentation positions or packaging states. Record how they were selected and which part families remain outside the trial. A demonstration using hand-selected perfect samples may establish basic feasibility, but it leaves questions about ordinary incoming variation unanswered. Ask the supplier to identify which variations its gripping and sensing strategy is designed to handle.

Hypothetical trial design: a buyer supplies 24 samples divided among small, medium and large members of a product family. Each sample retains an identifier throughout the demonstration. That number is an illustrative organising choice, not a reliability sample-size recommendation. Use the trial to discover unsupported assumptions and decide whether a larger, statistically designed production study is needed. FAIRINO's peripheral configuration documentation helps anchor the record to the actual gripper setup, while the buyer owns the representativeness of the samples.

References: User Manual 3.8.3: Peripheral configuration

Measure acceptable output and the complete cycle

Define the start and end events before measuring time. For example, start when a valid part is available with the required machine permission, and finish when the part is released in its accepted destination and the station is ready for the next agreed step. Record fixture waits, inspection and relevant communication delays. The event definitions should match the business question being answered, including any deliberately excluded upstream or downstream activity.

Create a separate quality result for each sample using the buyer's inspection method. Record failed grips, rejected output and manual corrections alongside successful cycles. FAIRINO's Status chapter documents system logs and status queries; request relevant records to help explain events, but retain the independent inspection result. Report the range of observed cycle outcomes and conditions instead of selecting the fastest movement as the machine's production rate. A short demonstration cannot establish long-term availability.

References: User Manual 3.8.3: Status, logs and queries

Test recovery with approved scenarios

Ask the integrator to prepare controlled tests for plausible process interruptions such as an absent part, unavailable downstream station or missing ordinary process confirmation. Each scenario needs an initial state, expected response, operator message and authorised recovery path. Use simulation or a reviewed test fixture where appropriate. Do not disconnect safety circuits, force a collision or introduce a dropped-load hazard to create a dramatic demonstration.

Observe whether the operator can tell what happened, where the part is and what must be checked before continuation. Include the state of peripheral equipment in that explanation. FAIRINO's Safety chapter distinguishes emergency and protective-stop configuration topics, so keep safety-function validation within a separate qualified procedure. For the buying demo, score the clarity and completeness of the planned recovery evidence, and record any scenario that could not be tested under the agreed controlled conditions.

References: User Manual 3.8.3: Safety configuration

Preserve failures as useful evidence

Agree how the supplier will record alarms, unexpected pauses and interventions before the first test. Give each event a time, sample identifier, process step, observed behaviour and proposed explanation. Distinguish an observed fact from a diagnosis: the robot paused during withdrawal is an observation, while an incorrect tool setting is a hypothesis until the supplier establishes it. This makes technical follow-up more productive and avoids turning a demo into an argument about recollection.

FAIRINO's appendix provides controller and servo fault references. Ask the supplier to connect an applicable error to its documented meaning and then substantiate the cause in this setup. An alarm that clears is not automatically a resolved defect. Record the corrective action and the repeated tests that support closure. Keep unresolved events visible in the final report even if the remainder of the demonstration is successful; they may determine what must happen before an order or shipment.

References: User Manual 3.8.3: Appendix, controller and servo fault references · User Manual 3.8.3: Status, logs and queries

Include a handover demonstration

Ask the supplier to show how your authorised team would identify the running project, locate its records and create the agreed backup. FAIRINO's Application chapter describes backup data and import verification. Require an explanation of what is included, what must be preserved separately and what conditions apply to restoration. A downloadable file is useful evidence of export, but it is not by itself proof that the complete application can be recovered.

Have a suitably trained representative follow the proposed operating instructions within the controlled demonstration, with the specialist supervising. Note where the instructions rely on undocumented knowledge. Request editable project material and a clear support contact if those are part of the purchase scope. Where a restoration rehearsal is appropriate, have the supplier plan it on compatible equipment with the necessary review; do not erase a working system merely to make the demonstration more comprehensive.

References: User Manual 3.8.3: Application, data backup and import verification

Issue a bounded acceptance record

End with a result for every agreed requirement: passed under stated conditions, failed or not tested. Attach the configuration record, sample results, event log and unresolved issues. Identify who accepts the evidence and who owns each remaining action. Avoid conditional passes that conceal the condition in an email thread. A requirement awaiting a replacement tool remains open until the revised assembly has been evaluated against the affected criteria.

Use the outcome to make the next purchasing decision concrete. You may have enough evidence to commission detailed integration, request a revised proposal or schedule a factory acceptance event. Name that decision without implying that the whole installation is approved. Preserve the evidence package as the starting point for later acceptance so that substitutions, site differences and application changes are examined deliberately. A valuable demo reduces uncertainty and makes the remaining uncertainty easier to manage.

References: User Manual 3.8.3: Foreword and important safety description · User Manual 3.8.3: Status, logs and queries · User Manual 3.8.3: Application, data backup and import verification

Checklist

• Agree buying questions and pass criteria in advance.
• Identify the complete tested hardware and software configuration.
• Label representative parts and record their selection.
• Define cycle boundaries and independent output inspection.
• Use only reviewed, controlled recovery scenarios.
• Retain alarms, interventions and corrective-action evidence.
• Demonstrate agreed backup and handover tasks.
• Issue passed, failed and not-tested results with owners.

Common questions