machineagency / taxon Goto Github PK

Feature requests:

• resolve above issue with machine instantiation and ids—probably easiest just to remove ids
• add model upload back in (only stl—at scale)
• add world ruler
• load model graphically into work envelope and do static checking there
• remix and duplicate rather than raw new (addresses above issue)

Support e.g. bridge length, overhang angle, and dimensional accuracy in a print. Allow the user to enter the results and tie it to a machine. Create a class to represent this information. Allow user to ask simple queries using the response maps.

idea for SM-fine: just parameter settings. these are compared against clustered data (unsupervised learning) coming from either past prints or an online repository of prints. we condition clusters on: model features and machine topologies from SM-coarse. E.g. people using a prusa typically used 2 more of parameterX versus other 3d printer, 1 more than gantry systems, and 2 more than other platform-moves systems.

(clamp and vise support)? maybe

Revamp the interface to support higher level questions somehow for someone who knows nothing about machines. For example, using a constraint we already have of having the model fit in the work envelope, either have some annotation, or check boxes e.g. "model fits in container," for hard constraints. For soft constraints, this is trickier; consider the example of driveTrain type, maybe explaining tradeoffs and using that to fill in the JSON. In either case, having just the raw JSON filter isn't super usable.

Idea: create an share a working demo (every 2-3 weeks), demo to lab, maybe post to Twitter.

• Files printed and simulated. Kinematic checks.
• End-Products visualized and formalized e.g. plastic cup, wooden cup, Matthew dot task.
• Task and Machine spaces visualized (small-scale). Mappings. Put visualization in the UI and let people play around with different machines.

Implementing RoTs, checking heuristics, having its own widget.

Based on our invariant.

Drop down for heuristic, then based on heuristic, drop down for operator, then possible values (e.g. slider or radio boxes).

From form data, synthesize query that executes immediately.

Enforce invariants such as:

• A spec must have all the required properties like blocks
• A stage must have the correct number of driving motors

Add more later

• LHS machine database, current machine program
• RHS procedure UI
• port file upload to procedure calls
• allow for stepping through procedure calls
• toolpaths get their own instruction window (existing one)
• keep warning/ui box

• Detect overhangs (in 3d case)
• Detect fine features (how to do this?)

Expand from simply having price to listing an object with price, sourcing, how many people have it, etc. to help beginner users make informed decisions.

Implement the checking as part of the GUI—think about how to do this checking. My hunch is that we need to revive the bottom frame.

Hard constraints to check

• Work envelope
• Correct type of machine
• Correct number of dimensions

Soft constraints

• Price and community info
• (Reach goal) is this a complicated model? Should we check sm-fine programs to see if it can handle it

• prusa
• axidraw
• othermill
• hot wire cutter
• wasp printer
• pick and place
• em printer
• matchsticks
• jubilee

Including any changes that we need to make to accommodate these, e.g. delta bot kinematics.

Don't do parts assembly yet.

Specifically, toggle visuals for: kinematic paths, dofs maybe, root nodes, work envelope.

This may require showing stock material, but as far as I know we would want to defer stock to SM-fine. Will think about.

Specifically, check: is it possible for the tool plunged to maximum depth to crash into the stock? Is this a model-level or CAM-level check?

• drive mechanism
• structural loop: “cantileveredness” gantry pushes straight down, robot arm has to distribute
• evenness of work envelope
• has moving XY platform

Main idea: the "stages" should look like wireframe or transparent boxes with actual machine parts inside e.g. a leadscrew or timing belt, even though these parts are purely cosmetic.

Connections should be marked probably as a transparent bounding box with labeling information.

Somehow embed unit information in SM-coarse programs. Exactly how to do so requires some thought. Some leads.

• post on units as quasi-dependent types (?)
• onshape featurescript units

My initial thought: use constants like "mm" and "dollars" in SM-coarse program. Desugar all unit-ed properties into default units when converting to json. Resugar when displaying the program—possibly just using the units we want.

During a comparison preview:

• Render the current machine as red (or some colorblind-ok color)
• Render both work envelopes
• Render labels on both machines in the scene

Keep thinking about this and how this might work.

Perhaps: previewing model sizes of recommended models, highlighting tools that would be needed on jubilee or another tool changing machine, or highlighting part of the machine that deserves extra attention for a particular model/job.

If we characterize structural loop, maybe we can project parts of the Axidraw work envelope that are subject to more wobble (calculating this is possible with volumetric and drive mechanism data, but not trivial), and give an interface to move the drawing away from those zones if there are fine features.

More importantly, this would enable live editing of machines.

Click on simulation, highlight corresponding code in editor.
Click on editor, highlight corresponding block in simulation.

Attributes: step displacement ratio we calculate (it's a distance). Person could know: kind of motor, what kind of gear—we calculate distance -> full rotation of motor corresponds to 2mm travel e.g.

E.g. never use milling with jubilee because it uses timing belts.

mechanisms give constraints. : speed, backlash, force -> “this machine can move quickly in xy but not z”

Doesn't have to be fancy

tool characteristics e.g. wattage, horsepower for spindle are uninterpreted. just set baseline recommendations outside the language. jk interpreted: just rules of thumb.

• By default add parallel stages on the ends of the longest axis in a ParallelStage
• For a CrossStage add either the old moving stack (e.g. Axidraw) or gantry (e.g. Jubilee), perhaps have these specified by an optional property.

There are on-action RoTs, and there are "always" or "what's feasible" RoTs, and the latter can be used to filter machines (possibly given no other constraints, or given constraints with materials or models). Find a way to identify these quickly but also use them to filter machines.

Up/down for plotter, extrude cylinder for printer, spin spindle for mill.

Aesthetic:

Can port over stuff from previous mom

Materials: on the the topic of where materials go, maybe just have them in a procedure call, with static checking about what machines work with what materials.

Regions and Sensors: These don't go in the machine—they are only instantiated with library calls. Try to have minimum effort here.

• Per-line preview (running) so that somebody typing let material = ... sees the stock loaded in the window
• Static checking e.g. if you use wood with a 3d printer it should error

Backus-Naur, baby.