Reconsider program–installation hierarchy in PolyScope X

Product Wishlist
1

Summary

Rework the relationship between programs and installations in PolyScope X to allow shared, reference-based installations independent of individual programs.

What is it?

This feature request concerns the architecture and lifecycle of installations in PolyScope X and their relationship to programs.

In PolyScope X today, the installation is logically embedded within the program. Safety settings, I/O configuration, fieldbus configuration, tool setup, etc. are all subordinate to a single program file.

We request a rework of this relationship. From a user perspective, there are several viable solutions:

  1. Reference-based installations
    Installations can be created, saved, and managed independently, and programs reference an installation (e.g. selectable when creating a program, or changeable later).

  2. Separation of program and installation (as in PolyScope 5)
    Installations exist independently and are not owned by individual programs.

  3. Reversed hierarchy
    An installation becomes the top-level entity and can contain multiple programs (URPX files).

The key requirement is that multiple programs must be able to use the same installation without duplicating it.

Why is it needed?

Current limitation

When installations are subordinate to programs, every program effectively owns its own copy of the (same) installation. (Right now, this copy step is even not possible, one has to just redo all the same single settings.)

Even if installations become exportable or copyable, this still results in:

  • Multiple cloned installations

  • No single source of truth

  • Configuration drift over time

This architecture creates major challenges in real-world automation scenarios.

Concrete customer problems

In our upcoming project, a single UR12 robot will operate with a large number of programs (on the order of ~100), all of which require exactly the same installation (safety configuration, I/O, fieldbus, tool data, payloads, etc.), as they are also physically used on the same setup.

With the current PolyScope X model, where the installation is subordinate to the program, this results in having to copy all single settings (and repeat this step for each change).

Even if installations are exportable and importable, this does not solve the underlying problem, as it still creates independent copies that can diverge over time. As a SW Engineer, I also don’t like this approach as it violates the DRY principle. I hope your SW Engineers agree and are motivated to change that :slight_smile:

5 Likes