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

Зачем им? Этого ни у кого из средних систем нету, на сколько я знаю. Тот же DriveWorksXpress может? Нет. А это жеж флагман. А раз на рынке нету - значит и не надо это никому.

Да. Одно из требований было таковым.ПиДиЭм нам сверху был ниспослан, и это был не ДОКс.
Хотя и в ДОКсе, вроде бы, достаточно широкий поиск было бы реализовать затруднительно.

Что за нагружение?

Круто. Реально.Просто в данном случае есть несколько фишек:
1. Возможность использования примененок. САПР каждый раз проверяет: есть ли необходимость разрабатывать новую деталь/узел или можно использовать что-то из ранее разработанного. Потому в диалогах и предлагается ввести возможные отклонения на входные величины.
2. Я не зря показал последовательно САПР ступени и САПР марша. Эти модули сделаны так, что они могут запускаться автономно или подключаться к другим модулям. В САПР марша не вписан САПР ступени. САПР марша формирует задание для САПР ступени, запускает его и потом использует результаты. Так же можно использовать САПР марша в САПРе более высокого уровня.
3. Все входные данные сохраняются на сервере с привязкой к объекту.
4. Базы данных моделей и данные по изменениям документов так же хранятся на сервере. Обеспечивается многопользовательский доступ к ним.
5. Access предоставляет достаточно мощный аппарат обработки данных "высшего" уровня - запросы, формы, макросы, отчеты. Одна из задач была - сделать САПР, который не требовал бы знаний языков программирования.

Вот такие примерно резоны были.

Ниче не препятствует использовать в данном случае штатный способ привязки - с помощью ЛСК. Каким образом и где их расположить - решать вам. Только вы знаете как и могут изменяться эти тела в перспективе, какие элементы являются присоединительными.
Ниче не препятствует сделать такую сборку путем "сверху вниз", ну если только не планируется выпуск групповых документов.

Хочу показать одну свою нароботочку.
В моей практике частенько встречаются задачки, когда нужно чуть-чуть переделать то, что уже много-много раз делалось. Этакие типовые задачи, с которыми заранее все понятно. Возник вопрос: а че каждый раз с ними возиться (хоть не много, но все же приходится), если алгоритм решения их ясен? Нельзя ли их автоматизировать до уровня (условно): "нажми на кнопку - получишь результат"?
Попробовали. Вот что получилось:
Есть две немудреные модельки - ступенька и марш лестничный.
Ступенька входит в марш, само-собой.
Ниже два клипа работы САПР, первый - модуля ступени, второй - модуля марша.
Модули сделаны так, чтобы после ввода исходных данных, САПР прошаривал ранее разработанные узлы на предмет поиска подходящих и если таковых не обнаруживается, то производил разработку новых узлов с выпуском новых документов и изменением старых.
После работы САПР пользователь получает отчет с перечнем новых и измененных документов. После этого ему надо их открыть, обновить, распечатать и подписать. Вот это я имел в виду под "под ключ".
Ступенька:

Марш:

А кто-нибудь делал подобные вещи? Имеют ли такие проекты перспективу какую-нибудь?

А я все жду: кто меня в пересечение межполюсных тяг (голубых) и заземляющих ножей носом ткнет.
А если серьезно, то моделька эта презентационная и лучше ей быть пока не нужно. А чтобы она хоть на что-то большее годилась, надо ее облизывать и просчитывать. Но заниматься этим я планирую только в случае, если кое-кто на это денег выделит. Се ля ви.
Так что увы, я - пас.

Ну там все по-честному. Положение трех из шести поворотных колонок и обоих заземлителей рассчитывается исходя из заданных длин тяг и рычагов (через пересечение вспомогательных тел - сфер и цилиндров). Так что модель достаточно близко отражает механику реального разъединителя. Все регулировки адекватно работают.

Ну надо жеж попробовать, чтобы знать на что рассчитывать при случае. День - не так много, на самом деле.

Спасибо!
Попробовал. День проковырялся и понял, что ну его на фиг! То работает, то "каменеет" все без особых причин. Повторяешь вставку заново - опять работает. Потом. В общем сделал все на ЛСК. Вроде то, что мне надо было на этом этапе получилось.
Как-то вот так: https://youtu.be/MPOM72JU84g

Доброго времени суток, коллеги.
В настоящее время есть у меня задача разработать разъединитель. Это аппарат (если кто не знает) с какой-никакой кинематикой. Захотелось сделать красивую полнофункциональную модель. Приходится использовать сопряжения. И вот в чем мой вопрос:
В мануале TF-12 есть такая фраза: "Для создания сложных сборок в системе реализован механизм «Агрегатов». Данный механизм позволяет создавать сопряжения сначала в модели 3D фрагмента, которые впоследствии автоматически будут учитываться при работе такого 3D фрагмента в сборке." И это всё. Больше про эту возможность ничего не нашел.
Попробовал сам, создал фрагменты со заданными для их отдельных частей степенями свободы, но при вставке в сборку они "каменеют".
Как быть? Посоветуйте, плиз.

Всё! Вчера ночью не разглядел. Это то, что нужно! Огромное спасибо. Обновлю библиотеку - выложу, может кому интересно будет.
Тему можно закрыть.
Еще раз: огромное спасибо!

Писал уже: вариант реализации через синтез в редакторе переменных возможен, но не оптимален. Это - запасной (и уже имеющийся) вариант.

Очень просто. В файле обе ситуации. Нужно чтобы обе переменные ($Str_01 и $Str_02) отображались бы одинаково - как $Str_01.

Ну давайте попробую.
По роду деятельности приходится много работать с деталями/сборками из проката. Имеется достаточно обширная наработанная библиотека профилей. И все в ней хорошо, да что-то не хорошо. А именно - заполнение материала в основной надписи и других местах. Есть 100500 способов решить этот вопрос, но хочется же получить окончательное решение.
В результате мне видится удобным следующий вариант:
1. Базы данных профилей оформляются как внешние.
2. Для работы с профилями делается специальный прототип, к которому заранее подключаются базы.
3. При создании документа, вы выбираете параметры сортамента и материала, при этом на автомате выбираются соответствующие ГОСТы (естественно).
4. Из специальной базы (внешней) для выбранных ГОСТов в соответствующие переменные считываются шаблоны записи материала в:
- основную надпись;
- спецификацию единичную/групповую на 10 исп. (для бч-шек);
- спецификацию на 3 исп. (для бч-шек опять же);
- другие, если надо.
5. В переменные с шаблонами подставляются определенные в документе переменные материла и сортамента.
6. Переменные с шаблонами отображаются в тех местах, для которых созданы.
Win!

В принципе все вышеописанное уже реализовано. Затык только со строковыми шаблонами в которые не желают подставляться переменные.
Мелочь (говорю же: есть 100500 способов заполнить материал от полностью ручного, до полуавтомата), но хочется же сделать один раз и забыть.
Я наверное ленивый?

Я что-то не правильно понимаю?

Это финт интересный, кстати. Я про такое не знал. Запомню на будущее.
Но в моем случае вряд ли применим - база внешняя по ссылке, расшаренная к многим файлам.
Поищем и еще пути. Может че-нить с кодировками символов можно сотворить? Хотя запись скобок через юникод ничего не дает - проверено.
Продолжу завтра. На Урале уже 2 ночи. Спокойной ночи, спасибо за попытку помочь.

Не то.
Вообще тыкаюсь сейчас в редакторе переменных, варианты всякие пробую и вижу, что с этими скобками фигурными засада.
Например, вот результаты выполнения строковых операторов:
"{"+"a"="{a"
"a"+"}"="a}"
"{"+"a"+"|"="{a|"
"|"+"a"+"}"="|a}"
"{"+"a"+"}"=ошибка
Это при том, что переменная а существует.

Ну вариант с логическими операторами понятен и даже реализован. Но при увеличении количества вариантов становится он несколько громоздким. Хочется порешать поизящнее.
Забавно, что конструкции типа [[... ~ ...]] или <<... ~ ..>>, считанные из базы, tf воспроизводит правильно, а вот с фигурными скобками не проходит. Может неспроста?