spacetimeengineer / mupy

Python Manufacturing Utility or "mupy" is a powerful new digital-twin technology. In it's essence, a new way to think about design, physical hardware, advanced assemblies, innovative technologies, or most generally, system design.
Other
12 stars 2 forks source link

V1 Requirements Upgrade Wish-list #12

Open spacetimeengineer opened 1 year ago

spacetimeengineer commented 1 year ago

1.) Hardware class may need to be called Ware class. More research is going into this. The reason is that Hardware may be too specific. A ware class is more general.

2.) Map Namespace, Workspace, Assembly, Ware -> Namespace-Code, Family-Code, Type Code, (Wares are not included in family unless there are made from direct scad or some similar situation in the script)

3.) mupy is more appropriate as an aspect of a larger Linux image since it is easier to leverage entire Linux system rather than upgrade python package to do everything. This way an ecosystem can be formed and preexisting lots leveraged.

4.) The Linux image will have an ip-address or some unique system for providing a namespace or a shop. A shop is a directory that lives at a namespace. A market is a server object which possesses a payment system and can allow shops to interact and it can sponsor discussions.

5.) When you execute a script it makes a whole family code system with instructions and parametrizations.

6.) Auto Certification

7.) Auto Manual : Derived from new Dimension object maybe and other things.

8.) Auto Encoder : This function is hard to build but is a collection of well designed smaller functions.

9.) Implement Market, Shop, Work objects This should be build as a new project altogether and then integrate mupy.

10.) Need new abstraction layer for discerning scad object and things that do not need to be scad objects.

spacetimeengineer commented 1 year ago

New Formalism Shop -> Work -> Item -> Dims

systemcode : http://someurl.com/shop/CUBX21-BLK8-H5F6T7Y4V48NGF765SD436

workcode : CUBX21

itemcode : ITG6

dimscode: H5F6T7Y4V48NGF765SD436

work = Work("CUBX21")

item1 = Item("ITG6", Coordinates(...)) item1.include("http://anotherurl.com/another_shop/POKC9-GH7-H300GY7679J878",Coordinates(...)) item1.include("http://anotherurl.com/another_shop/POKC9-GH7-H100GY7679J778",Coordinates(...)) item1.include("http://anotherurl.com/another_shop/POKC9-GH7-H250GY7679J678",Coordinates(...))

Each system code can be included in an Item object : work.run(item1)

spacetimeengineer commented 1 year ago

System codes now have new meaning, when a script is run, an entire 'work' code is created. Every type is now an assembly, hardware or more generally, and item.

Any variables that are created and utilized in the dims code's or the type code or the family code will be built into the encoding decoding system.

spacetimeengineer commented 1 year ago

These dims fit into the picture by helping instantiate a new automatically generated dims code. The work and item codes can be randomly generated or can be named.

spacetimeengineer commented 1 year ago

It is important to note that he workspace directory in the original code creates a rendering..... This is not technically the same as a library directory or a shop directory but it is similar. For this reason Work.run() is not the same as Work.cert().

spacetimeengineer commented 12 months ago

The encoder object will provide information as to which item code it attaches to or instructions of some sort. Still working out the kinks in the model and the prompts should be run if the work.run() is called. Do we assign encoders to the work or item object? Item most likely but the real question is is how prompts are given. When you certify the library is appended to with new works. If you run then the encoder should be run from the outset before anything is implemented otherwise you do not have the system codes. I do not think a default is default-ly appropriate given the situation.

Just realized that the entire work needs its own referencing of the encoders. The reason for this is that the whole purpose of the scripting interface mupy provides is that it can in theory assign a new system code structure for that assembly configuration defined by the script. This new system code requires inputs which will be available to the items within the works who require them for other system codes or something else entirely. Since this is itself considered genuine work it deserves its own work code.

Keeping self discussion here for historical purposes. Need to remember why we do things the way we do.

spacetimeengineer commented 12 months ago

radius_encoder = mu.InputEncoder( prompt = "Enter the desired radial length in millimeters:", long_description = "Radial length in millimeters.", label = "RD", input = "alphanumeric" default_value = 8, units = "mm" )

panel_b = mu.Item("PN45", "SPHER34-FG6-RD#GK789") # The '#' like the 'P' is special. Represents an encoding variable

panel_b.assign(radius_encoder)

work.certify("/home/non_standard_works_lib")

work.run(panel_b)