Latest revision as of 09:29, 5 May 2024

Machine phase

Machine phase & why

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

• essentially necessary for gemstone metamaterial technology to work at all and is
• a key factor for the high performance of gem-gum technology way beyond what soft nanosystems could ever deliver.

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

Using the global frame of reference for the representation off the data for the whole trajectories for the diverse component trajectories would be rather impractical.

Instead to confirm existence (existence meaning "already assembled") and
locate a part (sub-component of a product) in space at some given time 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"

Arrival-departure boundary condition matching

Main page: Arrival-departure boundary condition matching

Implementing robotic motions in local frames of reference (and generalized coordinates) faces a challenge:
The boundary conditions must match up. That is:

• the spacetime event of part arrival from a preceding stage must exactly match up with
• the spacetime event of departure to a sequeling stage

Derivatives of motion should also match up (giving osculating curves)
to prevent jumps in acceleration (jerk spikes).

Matching motions at the control transfer transitions can be difficult/nontrivial,
but it needs to be done anyway for actual robot control.
Analytic auto-propagation of positional and temporal shifts is highly desirable
and is part of what makes a good parametric design.

Dangerous allures to imperative hell:

There are two aspects that make "Arrival-departure boundary condition matching" challenging
in a denotative rather than imperative model.

In the context of error correction there will be cases when
no part or an unusable part arrives when there should have been
a functional part arriving (messing up full determinism a bit).

• imperative model: Has a good part arrived as it should have? Yes/No? If yes: go on. If no: wait. (And tell other subsystems to wait too if necessary.)
• denotative model: use the (possibly recorded) and in retrospect timeless "streams of errors" to organize activity.

Open loop control going on with its thing oblivious that

(Non)Applicability of recursive definitions for robotics across assembly levels

For practical systems it most likely is not suitable to use recursive definitions for the robotic motions.
This is because the robotics across the assembly levels will look quite differently
when optimized to their particular tasks in their particular size scales.

Recursive definitions for robotic motions though are definitely useful for animations illustrating
the concepts of convergent assembly and higher throughput of smaller machinery.

The reason for why

• simple recursive definitions work for illustrating animations but
• simple recursive definitions do not work for actual serious systems is

is partly due to the big difference in branching factor.

In case of bigger branching factors (x32 in length and ~ x32000 in volume proposed in this wiki)
using recursion (top down or bottom up) is not much of use since the stages may not have enough of a common basis.

Illustrations need smaller branching factors in order to make visible what is going on in one picture as one context.
Given one has modeled at least parts of "the real thing" then one can of course
try tricks visualizing it. But that is challenging.
Different scaled vie-windows loose context. Nonlinar scaling across displayed screen area may be confusing ....
See: Distorted visualization methods for convergent assembly

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

• Machine phase
• Design of gem-gum on-chip factories
• Component logistics
• ...
• Open loop control
• Subsystems of gem-gum factories => Drive subsystem of a gem-gum factory

• Productive Nanosystems From molecules to superproducts
• Relations of APM to purely functional programming

• Nanofactory math based on continuity of throughput
• Level throughput balancing
• Gem-gum factory design parameters
• Parts magazines