Спецификация

[suslad 1]

Этот вариант реализуем начиная с Wildfire. Делаете все как обычно для единичной спицификации и добавляете три колонки для исполнений.

При формировании спецификации на исполнение используйте Model/Column Rep для 2-го и 3-го столбца и, соответственно, для 2-го и 3-го исполнений.

[Modnyi 0]

Этот вариант реализуем начиная с Wildfire. Делаете все как обычно для единичной спицификации и добавляете три колонки для исполнений.

При формировании спецификации на исполнение используйте Model/Column Rep для 2-го и 3-го столбца и, соответственно, для 2-го и 3-го исполнений.

Попробывал и почти получилось.

Переделал шаблон спецификации и создал на его основе спецификацию для сборки generic model. У меня все три исполнения представлены в виде Instance, т.к. все возможные элементы не содержит ни одно из них. Поэтому назначаю Column Model/rep для каждого из трёх столбцов в каждом разделе, который содержит rpt.qty .

Всё работает хорошо пока не дохожу до раздела Комплекты. После выбора исполнения и нажатия Confirm WildFire2.0 просто вылетает.

В шаблоне только раздел Комплекты содержит вложенные регионы. Хотелось бы узнать в этом ли проблема и если да то можно ли её как-то обойти не изменяя шаблон?

И ещё вопросик. Можно ли задать в шаблоне имя исполнения для каждого столбца? Было бы намного легче задавать имена исполнений по какому-то шаблону, чем вручную назначать исполнения для регионов.

[DRUGLORD 0]

suslad

Есть вопрос поводу вашего варианта создания групповой спецификации:

Способ следующий.

В сборке есть возможность создавать параметры для компонетов (будь то деталь или подсборка). Их замечательное свойство как раз заключается в том что об этих параметрах сами модели деталей или подсборок "ни сном ни духом". Для их создания выбираем (в сборке!) Tools -- Parameters -- Look In -- Component -- Выбираем компонент сборки -- Ну и, собственно, вводим имя и значение параметра, например VARIABLE -- YES.

Далее дорабатываем форматку спецификации.

Во все регионы вносим следующую строку в фильтры:

&asm.mbr.cparam.name != * (именно CPARAM)

Это "говорит" системе не включать в наши регионы "переменные данные". Собственно это то чего мы и добивались.

Идем далее. Теперь надо создать форматку, которая будет отрабатывать только переменные данные (назовем ее форматкой переменных данных -- ФПД). Она будет почти точной копией стандартной форматки спецификации за следующими исключениями:

-- добавится надпись "Переменные данные для исполнений"

-- добавится обозначение исполнения

-- уберется раздел "Документация"

-- во всех регионах вместо вышеописанного фильтра ввести &asm.mbr.cparam.name == * (тем самым указываем что нас интересуют только переменные данные и никакие другие).

Подготовительная работа проведена. Пора переходить к практическому применению.

Открываем целевую сборку (конечно содержащую Family Table) и начинаем танцевать с бубном, ну, в смысле, давать знать некоторым компонентам что они являются переменными данными -- создавать в нужных компонентах параметры как описано в самом начале. Сделано? Замечательно, идем далее.

Создаем новый документ -- Report (вы еще не используете Репорт для спецификаций -- тогда мы идем к вам!!!) -- выбираем форматку спецификации -- вуаля, начало положено, есть спецификация на сборку с учетом отсутствия некоторых данных (ну тех, которые переменные).

Если надо -- делаем Pagination.

Далее, добавляем еще один лист и меняем в нем формаку на ФПД (напомню, Формака Переменных Данных). Результат -- отображение только переменных данных.

Первая часть мерлезонского балета закончена. Переходим ко второй.

Подгружаем исполнение в чертеж (или Report?). Активной моделью должно стать подгруженное исполнение (вас учили работать с мультимодельными чертежами?). Добавляем еще один лист и меняем в нем форматку на ФПД. Результат -- отображение только переменных данных ИСПОЛНЕНИЯ!

.........

n-я часть марлезонского балета. Одгружаем n-е исполнение и делаем все как описано второй части мерлезонского балета.

.........

"Фиксим" номера позиций (в смысле используем команду Fix), делаем Pagination, удаляем ненужные строки, переносим таблицы с листа на лист, в общем "обрабатываем напильником".

Итог -- групповая спецификация варианта А для вашей сборки.

Я использовал его не только для спецификации, но и для простановки позиций на чертеже, т.е.:

1. Вставлял таблицу с позициями при активной родовой сборке.

2. Активизировал нулевое исполнение и вставлял вспомагательную таблицу.

3. Активизировал первое исполнение и вставлял вспомагательную таблицу

4. И т.д.

При простановке позиций из регионов таблицы для родового исполнения проблем не возникало, а вот с таблицами , использующими неродовые исполнения, возникла неприятность следующего свойства:

Для того, чтобы номера позиций для исполнений не начинались с единицы, в графе "Поз." я использую символ отчета не @rpt.index, a @rpt.rel.index. Соответственно в уравнениях региона записана строчка "rpt_rel_index=rpt_index+0". И этот ноль можно изменить, скажем на 15, в результате номера позиций для этого региона будут начинаться с 16. Но!!!!!!

Когда проставляешь позиции на видах со ссылкой на упомянутый выше регион, позиции ставяться начиная с единицы. Оно и понятно, ведь символ позиции имеет в себе текст /index/, а следовательно ставит позиции без смещения, определяемого уравнением "rpt_rel_index=rpt_index+15". Пробовал сделать символ с текстом /rel_index/ и /rel.index/, но в этом случае нет ссылки на регион.

Подскажите, где я ошибся и как вы выходите из подобной ситуации.

Заранее спасибо.

[suslad 1]

Это решается довольно просто. Для таблиц с переменными данными используйте Table -- Repeate Region -- Fix Index. В этом случае номер присваивается жестко и именно он проставляется в выноске позиции.

[Ruslan 945]

Оно и понятно, ведь символ позиции имеет в себе текст /index/, а следовательно ставит позиции без смещения, определяемого уравнением "rpt_rel_index=rpt_index+15". Пробовал сделать символ с текстом /rel_index/ и /rel.index/, но в этом случае нет ссылки на регион

В Выносках региона, поменяй выводимый параметр.

Но лучше делать, как сказал suslad.

[DRUGLORD 0]

Для таблиц с переменными данными используйте Table -- Repeate Region -- Fix Index.

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

В Выносках региона, поменяй выводимый параметр.

А какой ставить, я ведь пытался:

Пробовал сделать символ с текстом /rel_index/ и /rel.index/, но в этом случае нет ссылки на регион

[Ruslan 945]

В символе ни чего менять не надо. /index/.

Table-Bom Ballons-Set Param, Сщелкаете по нужному Вам параметру (rpt.index), в этом регионе.

[DRUGLORD 0]

Table-Bom Ballons-Set Param, Сщелкаете по нужному Вам параметру (rpt.index), в этом регионе.

У меня руссифицированный ПроЕ, если правильно понял, то набор операций следующий: "Таблица\символы\задать параметр", на в пункте "Таблица" я не нашел "символов".

А можно подробнее? Я в общем-то описал ситуацию, так как мне поступить(не теряя связи с моделью), по какому параметру и где щелкнуть? Кстати, у меня не rpt.index, а rpt.rel.index.

[Ruslan 945]

Не знаю как по русски. Помоему просто Позиции или Выноски позиций. Щелкнуть по параметру который тебе нужен внужном тебе регионе.

[DRUGLORD 0]

Щелкнуть по параметру который тебе нужен внужном тебе регионе.

Большое спасибо, получилось, а можно-ли сделать так, чтобы символ сразу ссылался не на mbr.index, a на mbr.rel.index?

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

[Ruslan 945]

Можно использовать макрос для простановки позиций, где добавить установку параметра. Хотя от rpt.rel.index пора отказываться. Те проблемы что он решал раньше уже решены.

[DRUGLORD 0]

Те проблемы что он решал раньше уже решены.

Каким образом, если не секрет?

[Ruslan 945]

Пропуск позиций, увеличение позиций от региона к региону и т.п.

[DRUGLORD 0]

Пропуск позиций, увеличение позиций от региона к региону и т.п.

Это ответ на вопрос, какие проблемы уже решены, а я спрашивал:

Каким образом

[Ruslan 945]

В этом топике уже все расписано, по 5 раз. И примеры выложены.

Использование пустых регионов для пропуска позиций с фильтрацией по предыдущему региону (количество равно нужному пропуску).

Во всех регионах в Атрибутах стоит в качестве стартового индекса предыдущий регион и количество повторов равное 0.

Для работы с позициями в пределах региона существует функция фиксации индекса.

[DRUGLORD 0]

В этом топике уже все расписано, по 5 раз. И примеры выложены.

Использование пустых регионов для пропуска позиций с фильтрацией по предыдущему региону (количество равно нужному пропуску).

Во всех регионах в Атрибутах стоит в качестве стартового индекса предыдущий регион и количество повторов равное 0.

Для работы с позициями в пределах региона существует функция фиксации индекса.

О да, все расписано и все прочитано, но прочитано более внимательно, чем мои сообщения, все это я использовал, но со временем отказался, поскольку пропуски между регионами а)Нужны не всегда, б)если нужны, то в разных местах и разное количество. Как следствие, использовать пустые регионы нерационально, поскольку в каждом конкретном случае приходится преобразовывать структуру таблицы, да еще и проделывать это 2 раза (в чертеже и в спецификации). Кроме того, что, если нужно сделать пропуск в 15 позиций, пока создашь 15 регионов, быстрее специю вручную набрать, даже используя макросы. Аналогичная ситуация с фиксированием позиций, их в регионе может быть сколько угодно, я сталкивался с 25-30-ю, точно не помню, и помнож количество операций на 2 (в чертеже и в спецификации). В моем случае был вопрос касаемо переменных данных, которые отображены в отдельной таблице, позиции начинались с 42-й, а сборка имела 4 исполнения, на мой взгляд rel.index, это самый лучший вариант, кроме того, он еще и наиболее универсальный.

[Ruslan 945]

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

Не понятно почему и зачем?

Да и обходится это все. К сведению пустые регионы прекрасно размножаются либо просто добавлением строк, либо увеличением повторов. Плюс пустые регионы прекрасно фиксируются тоже.

Просто в переменной таблице добавь в начале пустой начальный регион (в уравнениях региона создать параметр asm_name) и фиксируй его с нужным смещением.

Я от rpt.rel.index отказался, так как с ним больше проблем. Есно rpt.rel. я мспользую, но для других целей.

[DRUGLORD 0]

Плюс пустые регионы прекрасно фиксируются тоже.

Честно говоря, не представляю, как, ведь при фиксации нужно указать на фиксируемый параметр, отображенный в ячейке, а ячейки пустого региона тоже пусты, нечего указывать для фиксации. Но я в-общем-то хотел сказать, что уж очень муторно фиксировать позиции, если в регионе много компонентов, например для сборки в 120 деталей и 70 наименований крепежа. При такой работе непонятно, зачем вообще использовать простановку позиций в регионах, если все-равно их вручную забиваешь? А если потом вспомнить, что ту-же работу надо провести в спецификации, то вообще плохо становится. Тут еще главное не ошибиться, дабы позиции на чертеже и в специи не различались. Но это еще пол-беды, а если ведущий возмет, да и добавит в сборку десяток деталей, а пяток уберет, сколько будет работы с перефиксацией? Другими словами я остаюсь при своем мнении:

на мой взгляд rel.index, это самый лучший вариант, кроме того, он еще и наиболее универсальный.

[Ruslan 945]

Честно говоря, не представляю

Проверено.

У меня с точностью до наоборот.

Так в регионе с компонентами, ни чего фиксировать не нужно. Ведь фиксация используется для тех же случаев, что и изменение пропусков позиций между регионами с помощью rpt.rel.index.

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

У меня с точностью до наоборот. В итоге получается выше скорость работы и ошибок меньше, проверено на опыте..

Тебе для начала нужно познакомиться с этой функцией.

[DRUGLORD 0]

Тебе для начала нужно познакомиться с этой функцией.

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