Describing MTConnect Tasks (e.g. MOVE_MATERIAL) in a robot-agnostic way (continuing from #613)

[idoco2003]

Continuing a thread from #613, which was auto-closed and locked (a housekeeping sweep, I think) a few minutes after @robot-ranger's comment, before I could reply. Moving it here so the conversation can continue.

Quick disclosure, same as on the issue: URML's prose, including this post, is AI-assisted under my direction and review (VIBE.md: https://github.com/URML-MARS/URML/blob/main/VIBE.md). The design and the review are mine, and this is a genuine design conversation, not a broadcast.

@robot-ranger you put your finger on exactly the seam. MTConnect's Task model gives you a TaskType like MOVE_MATERIAL that says what to accomplish, but not what to do physically, and pinning that to a URScript File Asset gets you the "what" while throwing away the agnosticism. That gap is what URML is built for.

Here is how the layers line up:

A URML program describes the physical task in substrate-agnostic primitives (pick_from the source, move_to the destination, place_at the fixture) composed into a behavior. That description is not UR-pinned. It validates against a declaration of the specific cell (the arm's reach, payload, gripper force, the CNC fixtures, a safety envelope) and only then compiles down to whatever runtime is under it: URScript for your UR arms today, something else on the next cell.

So a Task could reference a URML program as its work-to-be-done instead of a URScript file asset: the same "here is what to do," but universal and validated, which keeps the interoperability you would otherwise lose.

And it composes cleanly with the read-only side that came up earlier in #613: MTConnect tells you what the cell is doing, and URML checks what you are about to tell the arm to do before it is told.

You being the only ones actually running MTC tasks and interface models on real robots is exactly why I would want to get this right with you rather than in the abstract. I am happy to put together a small worked example: a MOVE_MATERIAL task whose physical work is a URML program, validated against a three-CNC-cell manifest, shown compiling to a UR target. No dependency on anything of yours, just to make the shape concrete.

Best way to go deeper is probably a call. I am at greenvh@gmail.com. Either way I would like to keep this going.

Ido

[robot-ranger]

@idoco2003 i moved the original issue to a discussion and closed the original issue. not sure if im talking to an AI agent or not but the discussion has been moved here: https://github.com/orgs/mtconnect/discussions/615

[idoco2003]

Thanks, and apologies for the duplicate. I opened this before I saw you had already converted #613. Let us keep it all on the original: https://github.com/orgs/mtconnect/discussions/615