Skip to content

MOTRAMechanical models, control and engineering checks

Parametric models, control records and log replay built from public engineering material, with separate software regression and independent geometry checks. Currently at local engineering validation.

Stage
Local engineering validation
Focus
Engineering R&D · Local validation
Records
2026
01 / Problem

Which assumptions behind the model are still unresolved?

Drawings, procurement lists and assembly models can disagree. Fix the source, parameters and signal contract first, and retain unresolved questions.

Parameter sources, signal contracts and open questions in MOTRA’s local reconstruction of public engineering material
02 / Build

Bring models, signals and run records into the same view.

Recorded software runs share a time cursor across the 3D model, control state and speed curves, so an anomaly can be traced to its original run context.

Public engineering model, curves and control states in MOTRA’s local software log replay
03 / Result

After a repair, check again.

Signal-mapping issues with a clear basis are repaired and put through software regression again. Questions that require equipment evidence remain open engineering items.

MOTRA software repair regression and open engineering questions; real-equipment validation is incomplete

The task and its users

This local MOTRA practice built a parametric mechanical model, control-state records and a log-replay interface, with geometry-check results kept separately. Engineers can inspect the model, control state and speed curves at the same time position and return to the run record where an anomaly occurred.

The engineering object comes from ONEARMY / Precious Plastic V2.0 public material. The scope is one rotor and one rotational degree of freedom. Drawings, procurement lists and assembly models differ in dimensions and component counts. Before modelling, the team needs to identify the source used, the basis for each parameter and the dimensions that remain uncertain.

Why we designed it this way

Displaying a model does not establish whether exported geometry is consistent or the assembly basis is correct. Parametric model generation therefore runs separately from STEP read-back and consistency checks. Generation records explain how the model was produced; independent checks assess whether the output meets the relevant requirements.

A normal-looking run cannot show whether a change introduced new problems. A signal-mapping error with supporting evidence can be repaired, but regression must run again afterwards. Questions with insufficient dimensional evidence or ambiguous fault attribution return to a person. Software repair records and open engineering items are kept separately, so resolving one software issue is not presented as approval of the entire machine.

What happens in practice

  1. Fix the inputs. Record the public-source version, chosen parameters and mapping between input signals and control actions. Conflicting sources remain open items rather than being silently reconciled during modelling.
  2. Build and check separately. Generate a native parametric model and independently read the STEP export back in. An open control state machine records inputs, commands and motion feedback. The model, state and speed curves share the same time cursor.
  3. Locate the anomaly and limit the change. Use run records to identify the conditions in which the anomaly occurred. Only issues with a clear responsible domain and basis for modification enter repair, followed by software regression using the saved configuration. Insufficient source material, ambiguous attribution or new regression failures stop automatic handling and return the issue to a person.

What can be checked now

The current stage is Local engineering validation. Read these three kinds of record separately:

  • Software log replay: inspect recorded states and curves to understand the context of an anomaly.
  • Re-execution with a fixed configuration: run the saved configuration again to check whether the software behaviour can be reproduced.
  • Independent geometry checks: inspect STEP read-back and geometry consistency, retaining differences in dimensions, component counts and assembly.

The three archived screenshots show sources and open questions, log replay, and repair regression. They support inspection of the adopted basis and software behaviour. Differences in the engineering material remain unresolved; the overall engineering assessment has not been rewritten as a complete pass.

Limits and next steps

Dimensions, component counts and assembly assumptions in the public material still need confirmation, followed by rechecking the affected models and software. Vendor PLC integration, physical-equipment trials, calibration with real material, industrial production and safety certification have not been completed. Software records cannot replace that evidence.

The next stage requires a PLC environment, equipment and material data, with separate acceptance conditions for integration, calibration and equipment trials. A pass at one level cannot establish a conclusion at another.

Attribution for public engineering material

The original engineering material is attributed to ONEARMY / Precious Plastic, with the fixed version precious-plastic-kit @ 4471659f928153867eee07f26c81dcec79793d76. Originals remain unchanged; source differences are recorded separately.

The engineering content and derived model images on this page are licensed under CC BY-SA 4.0. Website software and engineering content have separate licences. Modifications include parametric rotor reconstruction, coordinate conversion, control simulation and log-replay presentation, along with screenshot cropping, scaling and WebP encoding. Full details are in the public attribution file. ONEARMY / Precious Plastic has not endorsed this project.

Explore another project

PackProof / PPWR
Live product