Обзор фреймворка

Эта глава даёт мысленную модель, лежащую в основе фреймворка XMLProperties. Как только вы поймёте четыре ключевые идеи ниже, остальной синтаксис — это детали.

1 Для чего нужен фреймворк

Каждый настраиваемый объект CAM‑системы — технологическая операция, станок, инструмент, проект — описывается деревом свойств. У свойства есть имя, значение, тип, значение по умолчанию и метаданные, которые сообщают интерфейсу, как его отобразить, а движку — как себя вести.

Эти деревья свойств не пишутся в коде. Они объявляются в XML‑файлах дескрипторов и загружаются при старте. Это значит, что вы можете:

  • добавлять и удалять параметры операции или станка,
  • менять значения по умолчанию (в том числе отдельные для метрической и дюймовой систем),
  • перестраивать группировку и отображение параметров в инспекторе,
  • делать параметр видимым, скрытым, доступным или недоступным в зависимости от других параметров,
  • определять совершенно новую операцию или станок,

— и всё это редактированием XML.

2 Типы и экземпляры

Это важнейшее различие во всём фреймворке.

  • Дескриптор (тип) — это шаблон. Он говорит: «блок RoughPasses содержит логическое свойство Enabled со значением по умолчанию true и Step, равный 1 мм». Дескрипторы объявляются через <SCType> (а на верхнем уровне — <SCProperty>). Они образуют цепочку наследования: тип может базироваться на другом типе и расширять или переопределять его.

  • Экземпляр (указатель свойства) — это конкретное значение, привязанное к конкретному объекту: например, RoughPasses.Step у одной конкретной операции торцевания в вашем проекте. Экземпляры создаются из дескрипторов при создании объекта и хранят реальные, редактируемые данные.

Вы создаёте дескрипторы. Приложение создаёт из них экземпляры. Когда вы читаете или записываете значения через CAM API (см. Использование XML‑свойств из кода), вы работаете с экземплярами.

Важное следствие: экземпляр свойства, значение которого всё ещё равно значению по умолчанию из его дескриптора, не хранится дословно — оно вычисляется из дескриптора по запросу. Поэтому изменение значения по умолчанию в XML влияет на все существующие экземпляры, которые не были изменены явно.

3 Форма дерева дескрипторов

Дескрипторы вкладываются друг в друга. Дескриптор ComplexType содержит дочерние дескрипторы; те, в свою очередь, тоже могут быть составными; массивы содержат единственного потомка, который служит шаблоном элемента; перечисления содержат свои варианты как потомков. Поэтому дескриптор одной операции — это глубокое дерево, листья которого — простые значения (числа, строки, логические значения, выбранные варианты перечисления).

<SCType ID="TFinishPasses" type="ComplexType">
    <SCType ID="Enabled" type="Boolean" DefaultValue="true"/>
    <SCType ID="Step"    type="Double"  DefaultValue="1" DimensionKind="Linear"/>
    <SCType ID="Count"   type="Integer" DefaultValue="1"/>
</SCType>

Дальнейшая навигация по дереву (в выражениях и в API) использует точечные пути вида FinishPasses.Step.

4 Пространства имён

Дескрипторы сгруппированы в пространства имён. Пространство имён — это самодостаточный словарь имён типов: тип операции TSTFaceMillingOp живёт в пространстве Operations, тип станка — в пространстве Machines, и так далее. Два пространства имён могут содержать типы с одинаковыми именами, не конфликтуя.

Пространства имён объявляются через <SCNameSpace ID="...">. Один и тот же физический файл типов часто включается более чем в одно пространство (например, общий CommonTypes.xml включается почти везде), так что общие строительные блоки доступны там, где они нужны.

Основные пространства имён, которые вам встретятся:

Пространство имён Содержимое
Operations Типы технологических операций
Machines Типы станков и их кинематические строительные блоки
Project Схема проекта / установа
Application Настройки уровня приложения
Postprocessor Дескрипторы постпроцессоров
OperationRegistrator Небольшие «регистрационные» записи, объявляющие, какие типы являются настоящими операциями (см. Дескрипторы операций)

5 Как файлы загружаются и объединяются

Загрузка начинается с корневого файла (например, SCConfig.xml) и следует директивам <SCInclude>, собирая всю модель. Важны три правила:

  1. Порядок имеет значение. Файлы обрабатываются сверху вниз. Тип должен быть объявлен до того, как он используется в качестве базового, а более поздние объявления могут переопределять более ранние. Именно поэтому корневые файлы подключают абстрактные/базовые типы раньше конкретных, которые от них наследуются.

  2. Включения могут быть необязательными и с масками. Optional="True" означает «загрузить, если файл существует, иначе молча пропустить»; маски вроде *_ExtOp.xml позволяют добавлять файлы‑расширения в папку, не редактируя корневой конфиг. Несколько таких необязательных включений с масками указывают на папки вне Supplement — именно так ваш пользовательский контент загружается, не затрагивая системные файлы. См. §7.

  3. Пути используют файловые переменные. Вместо абсолютных путей включения (и ссылки на файлы, например иконки) используют подстановки $(VARIABLE), которые во время выполнения превращаются в реальные папки. Список см. в §7.

<!-- из SCConfig.xml -->
<SCInclude>$(SUPPLEMENT_FOLDER)\CommonTypes.xml</SCInclude>
<SCInclude>$(SUPPLEMENT_FOLDER)\Operations.xml</SCInclude>
<!-- необязательное, с маской, загружается только при наличии -->
<SCInclude Optional="True">$(LOCAL_OPERATIONS_FOLDER)\*.usrdef</SCInclude>

Не у каждого пространства имён есть корневой файл на диске. Сборка пространства имён — это просто «открыть пространство, загрузить в него последовательность файлов, закрыть». Эта последовательность обычно объявляется в XML (<SCNameSpace> + <SCInclude>), но приложение может также собрать пространство имён в памяти при старте, загрузив те же файлы строительных блоков по порядку. Пространство Project собирается именно так — единого корневого конфига проекта нет; система загружает CommonTypes.xml, ProjectSchema/CommonProjectSchema.xml, ProjectSchema/ProjectSchema.xml и ещё несколько в новое пространство Project. Результат идентичен декларативной форме — поэтому, если вы не можете найти корневой файл для пространства имён, вот почему.

6 Чем управляет фреймворк

Одно дерево дескрипторов питает сразу несколько подсистем. Понимание этого объясняет, почему дескриптор несёт столько разных атрибутов:

  • Модель данных — фактические значения, хранящиеся в проекте.
  • Интерфейс инспектора — подписи, группировка, порядок, иконки, видимость/доступность строк и специальные редакторы. Большинство «оформительских» атрибутов (Caption, Visible, Compact, Category, ImageFile, …) существуют именно для этого.
  • Вычислительный движок — решатели и конвейер построения траектории/УП читают значения свойств по имени.
  • CAM API — внешний код читает и записывает те же свойства.

Следующая глава — справочник по синтаксису, на котором всё это построено.

7 Куда помещать ваши файлы

Папка Supplement — это системный контент только для чтения: она перезаписывается при каждом обновлении, поэтому любые ваши изменения в ней теряются. Вместо этого корневые конфиги подключают ряд необязательных расположений с масками вне Supplement, зарезервированных под ваш контент. Положите свои файлы туда — и они загрузятся автоматически вместе с системными дескрипторами, в правильном порядке.

Расположения адресуются через файловые переменные, чтобы корректно разрешаться для каждой установки и каждого пользователя:

Что вы хотите добавить… Как Кем загружается
Новый / расширенный тип операции (автоматически по имени) положите файл *_ExtOp.xml в $(COMMON_CONTAINERS_FOLDER) Operations.xml
Новый тип операции (регистрация через мастер) зарегистрируйте XML‑файл операции в Operations Manager (см. ниже) → он добавляется в $(OPERATIONS_FOLDER)\UserOperationsList.xml Operations.xml
Переопределения пользовательских значений по умолчанию поместите файлы *.usrdef в $(LOCAL_OPERATIONS_FOLDER) SCConfig.xml
Пользовательский станок создайте его инструментами построения станков; хранится в $(SCHEMAS_FOLDER) / $(CUSTOM_SCHEMAS_FOLDER) подсистема построения станков

Рекомендации:

  • Операции — два способа. Есть два независимых механизма добавления пользовательской операции, и оба загружаются после системных операций, поэтому любой из них может объявлять новые типы операций или переопределять существующие:

    • По соглашению об именах. Положите файл *_ExtOp.xml в $(COMMON_CONTAINERS_FOLDER). Любой файл, подходящий под маску, подхватывается автоматически — больше ничего настраивать не нужно.
    • Через мастер Operations Manager (меню Utilities → Operations Manager). Вы указываете мастеру XML‑файл вашей операции (хранится где угодно); он регистрирует этот файл, добавляя запись в $(OPERATIONS_FOLDER)\UserOperationsList.xml. Этот список ведётся мастером — вручную его не редактируют.

    В обоих случаях сам файл операции — это обычный файл дескриптора (<SCCollection> в пространстве имён Operations); различается только способ его регистрации.

  • Станки. Пользовательские станки обычно создаются интерактивно приложением MachineMaker, которое записывает их кинематические схемы в папки схем станков, а не в Supplement. Рукописный XML — только для особых случаев; синтаксис дескриптора станка, на котором строятся эти схемы, описан в разделе Дескрипторы станков.

  • Читайте Supplement, но не редактируйте его. Относитесь к поставляемым файлам исключительно как к справочнику по шаблонам и базовым типам, на которых вы строите своё.

Механика одинакова, где бы ни лежал файл: тот же корень <SCCollection>, те же пространства имён, тот же синтаксис. Различается только папка.

Далее: Синтаксис дескрипторов