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

[suslad 1]

Кому-нибудь удалось хоть частично решить проблему выдычи спецификации с переменными данными для исполнений? Если еще и этому научиться, то будет просто песня.

<{POST_SNAPBACK}>

Я описывал как это можно сделать. У меня "в промышленной эксплуатации" используется создание групповой спецификации варианта А (с переменными данными для исполнений).

[DRUGLORD 0]

Я конечно, извиняюсь, но, что-то не заметил.

Честно, просмотрел все 15 страниц, нашел только фразы типа "Собираюсь делать", "Вроде сделал, проходит обкатку", "Еще не знаю как, но есть идея", "Уже пробовал, но ничего не получится" и т.д. Даже частичного способа не нашел.

Могу предположить, что читал несколько нерадиво, но от этого не легче.

Если не трудно, можно объяснить еще раз для дилетанта?

[suslad 1]

Я конечно, извиняюсь, но, что-то не заметил.

<{POST_SNAPBACK}>

Я тоже не нашел.

Придется проделать сей титанический труд еще раз.

Итак, идея -- надо "дать знать" некоторым компонентам сборки что они являются переменными данными. Но сделать это надо таким хитрым способом чтобы модели этих компонентов об этом "даже не подозревали".

Так как же это сделать?

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

В сборке есть возможность создавать параметры для компонетов (будь то деталь или подсборка). Их замечательное свойство как раз заключается в том что об этих параметрах сами модели деталей или подсборок "ни сном ни духом". Для их создания выбираем (в сборке!) 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, удаляем ненужные строки, переносим таблицы с листа на лист, в общем "обрабатываем напильником".

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

[Ruslan 389]

меняем в нем формаку на ФПД

Добавляем еще один лист и меняем в нем форматку на ФПД

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

У меня есть 2 заготовки таблиц для переменных данных. Их я и вставляю и состыковывыю по сетке.

[DRUGLORD 0]

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

Далее, добавляем еще один лист и меняем в нем формаку на ФПД

<{POST_SNAPBACK}>

что-то туговато.

Нет, с мультимодельными чертежами и Pro/report я работать умею, непонятно пока, как указать конкретному региону, на какую модель, т.е. на какое исполнение ссылаться.

Но это так, к слову, буду экспериментировать.

[suslad 1]

как указать конкретному региону, на какую модель, т.е. на какое исполнение ссылаться

<{POST_SNAPBACK}>

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

Добавляем в чертеж исполнение -- оно становится активным. Теперь любая ДОБАВЛЯЕМАЯ таблица с регионами или ДОБАВЛЯЕМЫЙ дополнительный лист будут использовать именно это активное исполнение во всех своих регионах.

[DRUGLORD 0]

Добавляем в чертеж исполнение -- оно становится активным. Теперь любая таблица с регионами или дополнительный лист будут использовать именно это активное исполнение во всех своих регионах.

<{POST_SNAPBACK}>

т.е. если задать активным определенное исполнение, то на него будут ссылаться только вновь добавленные регионы? Я прав?

[suslad 1]

т.е. если задать активным определенное исполнение, то на него будут ссылаться только вновь добавленные регионы? Я прав?

<{POST_SNAPBACK}>

Совершенно верно. Я же выше упоминал про работу с мультимодельными чертежами.

[DRUGLORD 0]

Спасибо, это получилось, а все-таки можно-ли обойтись без этих действий и свести все данные по родовой сборке и ее исполнениям в одну форматку? для получения одной автоматически генерящейся специи?

[DRUGLORD 0]

Добавляем в чертеж исполнение -- оно становится активным. Теперь любая ДОБАВЛЯЕМАЯ таблица с регионами или ДОБАВЛЯЕМЫЙ дополнительный лист будут использовать именно это активное исполнение во всех своих регионах.

<{POST_SNAPBACK}>

Это верно, но есть одна проблема:

когда таблицу с репит регионами (или без них, не важно) ДЛЯ ИСПОЛНЕНИЙ сохраняешь как файл таблицы, то в него не заносится информация о применяемых в ячейках шрифтах и размерах символов, они все сбрасываются в значения по умолчанию. Следовательно, при добавлении таблицы для исполнений все шрифты приходится переопределять.

свести все данные по родовой сборке и ее исполнениям в одну форматку? для получения одной автоматически генерящейся специи?

<{POST_SNAPBACK}>

Это ускорило бы работу.

[suslad 1]

Это верно, но есть одна проблема:

когда таблицу с репит регионами (или без них, не важно) ДЛЯ ИСПОЛНЕНИЙ сохраняешь как файл таблицы, то в него не заносится информация о применяемых в ячейках шрифтах и размерах символов, они все сбрасываются в значения по умолчанию. Следовательно, при добавлении таблицы для исполнений все шрифты приходится переопределять.

<{POST_SNAPBACK}>

А что за необходимость менять какие-либо шрифты внутри регионов таблицы? Там должно быть все настроено и лазить туда "низя"!

[DRUGLORD 0]

Там должно быть все настроено и лазить туда "низя"!

<{POST_SNAPBACK}>

Не пойму, почему это туда низя, всегда лазили и все нормально, а необходимость, конечно, условная. У нас этот шрифт при печати красивше

[suslad 1]

У нас этот шрифт при печати красивше

<{POST_SNAPBACK}>

Так надо свою форматку сделать со своими КРАСИВЫМИ шрифтами. И после этого

Там должно быть все настроено и лазить туда "низя"!

<{POST_SNAPBACK}>

[DRUGLORD 0]

Так надо свою форматку сделать со своими КРАСИВЫМИ шрифтами. И после этого

<{POST_SNAPBACK}>

Стоп, давай по-порядку, я так и сделал, НО!

при групповой спецификации нужно к ФОРМАТКЕ (с красивыми шрифтами) для каждого исполнения добавлять ТАБЛИЦУ (с регионами и т.д.) а вот уже в ней шрифты красивыми не сохранить.

Поскольку информация о шрифтах хранится в форматке, но не сохраняется в таблице (*.tbl)

[Ruslan 389]

Не знаю у меня тип шрифта и его начертание в таблице сохраняются.

[DRUGLORD 0]

Не знаю у меня тип шрифта и его начертание в таблице сохраняются.

<{POST_SNAPBACK}>

Возможно у вас этот тип забит по умолчанию.....

Или это работает лишь в ВФ3, (У меня ВФ2)

[Ruslan 389]

Нет.

Это работало и в 2001.

[suslad 1]

Поскольку информация о шрифтах хранится в форматке, но не сохраняется в таблице (*.tbl)

<{POST_SNAPBACK}>

Уважаемый DRUGLORD, PTC в учебных курсах РЕКОМЕНДУЕТ для передачи стилей текста из одного чертежа в другой использовать именно таблицу.

[DRUGLORD 0]

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

<{POST_SNAPBACK}>

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

[Modnyi 0]

Просмотрел всю ветку и на базе предложненных шаблонов и решений переделал спецификацию под свои нужды.

Всем спасибо

Но тут свалилась другая задача: надо сделать групповую спецификацию.

Я, конечно, попробую алгоритм, предложенный suslad, но мне хотелось бы реализовать вариант спецификации по форме 5 ГОСТ 2.113. У кого нет под рукой ГОСТа поясню. Когда исполнений не больше 3, можно увеличить ширину поля Кол-во стандартного бланка спецификации за счёт гарафы Наименование, разделить его на 3 части и в получившихся полях вносить количество каждой позиции в зависимости от исполнения.

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