Tracing trajectories of component in machine phase

From apm
Revision as of 08:25, 20 August 2021 by Apm (Talk | contribs) (How to represent the date of component trajectories)

Jump to: navigation, search

Machine phase

Machine phase & why

Gemstone metamaterial on-chip factories operate in machine phase.
Operating in machine phase is:

For a discussion of details see:
See: Machine phase, The defining traits of gem-gum-tec, Stiffness, ...

Machine phase & part tracability

Machine phase means (among other things) that a gem-gum factory is fully deterministic system.

  • That is: For any given time there is exactly one uniquely defined system configuration.
  • That is: There are no branches in the temporal trajectory of the whole configuration space.
    ("configuration space" is the entirety of all the actuator positions and actuator angles and similar – aka generalized coordinates)

As a visual mental aid one maybe can think of a gem-gum factories drive system like a slider on a (very complexly shaped) one dimensional rail.

So for any given atom in a gemstone metamaterial product the complete trajectory can be traced
right from where it was captured into machine phase.

The same holds for parts like crystolecules and microcomponents.
The trajectory of bigger components is also uniquely and fully tracable

  • Right from the moment of the parts completed assembly from subparts. From its "inception".
  • Till the moment where the part becomes assembled as a sub-part of one of the next higher up assembly levels components. And even further ...
  • All the way up to the release of the final macroscopic product into the "chaos in the human scale room phase" (overstretching "phase" here)

Machine phase & where it ends at the top

At a large enough product sizes the FAPP absolute determinism necessarily needs to end
because our macroscale reality is not totally deterministic. E.g.
(1) It can't be predicted what kind of product a user is eventually going to produce in the next production run.
(2) Most macroscale products are used
without being connected to the "ground" at all times AND
without having their position robotically controlled at all times.
The outside of space stations may be one of a few notable exceptions. The rigid main body station being the "ground".

How to represent the data of component trajectories

Representing the data for the whole trajectories for the diverse component trajectories in the global frame of reference would be rather impractical.

Instead for some given time combined with some given sub-component of a product one
fist looks up the mechanism that is at that moment of time responsible for keeping this component safely in machine phase.
This gives:

  • The pose coordinates of the responsible mechanism and
  • the rigid body pose coordinates (position and rotation) of the component in the local coordinate frame of reference.
  • (and a local frames of reference for time)

To decide:
What to call the machanism responsible for keeping the component safely in machine phase?

  • "owner" "onlatcher" "caretaker" "responsible mechanism" "guider" "controller"

Avoid imperative modelling

In any case a naive imperative approach of modelling is absolutely to avoid.
"Naive imperative way" means storing positions in variables making the
responsible mechanisms into "objects as actors" that look up the old positions and orientations
of components and in place update those values to represent a new time-step.
DO NOT DO THAT!!

Related