Одинаковые Названия Деталей

[sloter 546]

Sloter, тема про SW. В TF эти проблемы даже не возникают, но речь-то об SW идёт.

Согласен! Просто тема плавно перешла в концептуальную плосткость. И для меня было дико читать, как народ при создании деталей в процессе проектирования даёт им децимальные номера.

Что касается поиска файлов, то я их не ищу, а просто выбираю в проводнике Солида. Очень удобная штучка!

В принципе - да, но при количестве файлов, к примеру, от 1000 - сомневаюсь. Я в поиске просто вбиваю для атрибута обозначение - обозначение чертежа и система находит нужную модель. Можно конечно стандартным поиском по имени файла найти чертёж, а уж из него окрыть модель. Но если чертёж большой, то на его загрузку может потребоваться немало времени.

[VOleg 228]

У меня сейчас основные 2 папки. В одно 2700 (2006) файлов в другой 1800 (до 01.12) последние 2 проекта еще не добавил - на утверждении. Поиском тоже активно пользуюсь, но когда по черновикам или архиву ползаю, а в рабочих практически не требуется - классификатор все раскладывает - одно движение и уже в нужной группе.

[Ruslan 266]

Конечно, я в ней (СУПР) получаю всю нужную информацию, она висит у меня на экране. Но чаще распечатки просто лежат на столе. А классификатор у меня в Ворде оформлен. А удобно это или нет не задумывался. (Обсудим?)

Конечно.

Но лучше наверное будет развить идею дальше, и написать макрос проверки уникальности имени по вашей базе данных. Так как без ПДМ, SW сам это не проверяет.

По поводу классификатора, то может и на нево макрос тоже? Назначение имени в режиме диалога. У меня была такая идея, но руки пока не доходят.

А он уже вводит и распечатывает

Где то на форуме я уже это читал. И было высказано что ошибок при таком способе не избежать. лучше уж сразу настроить с нормальным видом и передавать в базу в более автоматизированном виде,чем ручной ввод.

Что касается поиска файлов, то я их не ищу, а просто выбираю в проводнике Солида. Очень удобная штучка!

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

Когда SW начнёт работать не с именами, а с адресами файлов, как AI или TF, такая проблема отпадёт сама собой.

Данная система имеет много недостатков, хотя как и любая другая.

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

И для меня было дико читать, как народ при создании деталей в процессе проектирования даёт им децимальные номера

Почему дико? Я их сразу назначаю, потому как сразу знаю к какому узлу изделия он будет принадлежать, сами детали есно в порядке создания.

Переменовываю на этапе окончания проекта, очень редко. Концепция изделия ведь известна из Технического задания да и прорабатывается еще до начала прорисовки на машине.

[ber2004 23]

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

Я это решил тем, что файл именуется комбинацией Обозначение-Наименование-пояснение. Подробнее - в текстах из поста <noindex>http://fsapr2000.ru/index.php?showtopic=2...st&p=184202</noindex> .

...наиболее правильно указывать децимальный номер детали в той или иной форме. .... Чертеж да, здесь я обоими руками за, по номеру, ... А деталь? Она ведь, в процессе проектирования, может, например, из вала превратиться во втулку, а номерочек-то уже присвоен.

Тут ИМХО не разные (по подходу к именованию файлов) объекты, а просто разные стадии проектирования. У меня в РКД модель и чертеж с нее строго одноименны. Но на стадии проработки - использую временные имена (и стараюсь, чтобы были уникальными - см. ниже), Перед оформлением КД - причесываю и переименовываю.

Но сохранить уникальность на все проекты - это ещё голову поломать надо

Это я решил тем, что на ранних стадиях файлы имеют временные имена по типу Тема-узел-подузел-деталь-вариант-пояснение. Все словами. Тема (или обозначение изделия) - уникальна. Уникальность остального - только в голове отслеживать. А к моменту оформления РКД уже появляются обозначения и наименования, которые в штамп чертежей пойдут и выдержавшие естественный отбор файлы переименовываются. (Переименование без потери связей несложно, но это за пределами темы)

Вот пришли вы в библиотеку: Дайте мне книгу АБВ автора ЙЦУКЕН. А бабуля вам:

А бабуля вам: "Их четыре издания и все разные" . Имя должно быть уникальным (как минимум в пределах фирмы)

[VOleg 228]

Но лучше наверное будет развить идею дальше, и написать макрос проверки уникальности имени по вашей базе данных. Так как без ПДМ, SW сам это не проверяет.

Давайте все-таки "имя" и "обозначение" не путать. Обозначение автоматом уникальное. И в базе и в Солиде. Обратите внимание, все файлы в одной папке, и если я ошибочно наберу существующее имя, то мне солид любезно подскажет. Но я еще проще делаю - выбираю последний файл в группе и меняю последнюю цифру на ту, которая мне нужна (почему-то чаще просто больше на 1). В базе тоже автоматически мне просто не ввести 2 одинаковых обозначения (наименований одинаковых сколько угодно) т.к. данное поле имеет соответсвующий "Индекс". А база реляционная (т.е. связанная).

Где то на форуме я уже это читал. И было высказано что ошибок при таком способе не избежать. лучше уж сразу настроить с нормальным видом и передавать в базу в более автоматизированном виде,чем ручной ввод.

Конечно, можно написать подпрограмму передачи данных, но для разных CAD они разные. Кроме того именно при вводе ведется много проверок. Администратор у нас по совместительству конструктор и ему дано много прав на внесение изменений.

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

Если говорить про "ДеревоПросмотра" и его объект "Node", то для описания стурктуры КД оно подходит "Из далека, в тумане, темной ночью" (Филатов). Для решения систем на его основе нужны супер программисты. Это Natta, TehnoPro, Teknologes - я им мысленно аплодирую. Они сделали гигантскую работу решив задачу используя такой инструмент. Я таким не являюсь. Поэтому я решил задачу идеально - с применением реляционных баз данных - а решение оказалось до смешного простым - всего две таблицы. И пожалуйста - дерево бесконечной вложенности, а применяемость и состав - это здесь одно и тоже. 2 года искал решение этой детской задачки.

Я их сразу назначаю, потому как сразу знаю к какому узлу изделия он будет принадлежать, сами детали есно в порядке создания

Я тоже сразу назначаю и тоже очень редко переименовываю. Если я рисовал втулку, то осью у меня она не становиться, а если втулка не понадобилась - ее просто уничтожаю и номер опять свободен. (сделать хотел грозу, а получил козу.... Алла Пугачева). ЭТО Я ШУЧУ!!!!

Другое дело, может назначать его автоматически?

Есть предложения?

[sloter 546]

Концепция изделия ведь известна из Технического задания

В таком случае я вам просто завидую. Из ТЗ, что обычно бывает у нас, можно получить только некий расплывчатый образ изделия. Как правило это общие слова - описание принципа работы и выходные параметры. Можно это конечно назвать концепцией в первом приближении, но о структуре, тем более о финальной структуре, оно представления не даёт ни какого - это точно. Структура определяется в процессе проработки вариантов конструктивых схем. Причём от варианта к варианту оно может меняться почти на 100%. Ну а финальная структура определяется собственно в конце разработки. Поэтому мы не знаем, да и не можем её знать в процессе создания деталей.

да и прорабатывается еще до начала прорисовки на машине.

Это как? Не на бумаге случаем? Как правило состав узлов определяется после определения деталей. Можно конечно состав продумывать и держать в голове, но это уже элементы кульманизма. К тому же зачем его определять на ранней стадии, если он постоянно меняется и тем самым появляются проблемы.

Это я решил тем, что на ранних стадиях файлы имеют временные имена по типу Тема-узел-подузел-деталь-вариант-пояснение. Все словами. Тема (или обозначение изделия) - уникальна. Уникальность остального - только в голове отслеживать. А к моменту оформления РКД уже появляются обозначения и наименования, которые в штамп чертежей пойдут и выдержавшие естественный отбор файлы переименовываются

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

[Ruslan 266]

Если я рисовал втулку, то осью у меня она не становиться, а если втулка не понадобилась - ее просто уничтожаю и номер опять свободен.

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

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

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

Есть предложения?

Есть.

У меня тоже 7 - значный "индекс разработчика"+уровень 1 цифра+"."+"конструкторско-технологическая группа" из 3 цифр+"."+номер регистрации из 3 цифр. VR4.574.043.

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

Что такое Уровень один - подозреваю что изделие, можно пробивать в настройках перед началом каждого проекта.

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

Далее программа ищет файлы с такой маской из первой части. После чего подставляет следующий номер детали или сборки если у Вас они не отличаются.

то как? Не на бумаге случаем? Как правило состав узлов определяется после определения деталей. Можно конечно состав продумывать и держать в голове, но это уже элементы кульманизма. К тому же зачем его определять на ранней стадии, если он постоянно меняется и тем самым появляются проблемы.

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

Если на примере автомобиля, то например

Привод

Корпус

Элементы управления

Элементы питания

Приводные элементы

Электрика

Присоеденительные элементы или аксесуары в общем случае (Багажник на крыше или прицепное).

Элементы безопастности

Элементы интерьера

и т.д.

[sloter 546]

Если на примере автомобиля, то например

Ну это понятно. Для таких давно известных изделий структура и схема конструктивного членения известна, не меняется, и вряд ли будет сильно меняться. Наша специфика - нестандартное эскпериментальное оборудование и изделия. Для этих изделий характерна новизна (оригинальность)конструкции и/или новый физический принцип работы. Прямых прототипов практически нет. Образ изделия определяется в процессе разработки в работе с заказчиком (наука). Поэтому заранее состав как правило не известен. А ТЗ... В привычном понимании конструктора серийных изделий можно сказать, что его вообще нет

[VOleg 228]

Ruslan

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

Что такое Уровень один - подозреваю что изделие

Первая цифра 0-2 изделия, комплекты, и пр. 3-6 сборки, 7-9 детали. Высокой скорости присвоения обозначений мне не нужно, а в СУПР дописывать не хочу. (что написано пером, то лень переписывать). Изделия у меня - примитивы, просто очень большие. Но даже примитивные - состоят из модулей, модули взаимозаменяемые в пределах каждого типоразмера изделия. В модуях блоки (условно) тоже взаимозаменяемые, в блоках агрегаты - взаимозаменяемые, в агрегатах - сборки взаимозаменяемые. Ну а детали практически все параметрические. Так что иногда изделие получается просто добавлением конфигурации с переключенными исполнениями (конфигурациями). Можно и наоборот - изделие состоит из агрегатов, агрегаты из блоков, блоки из модулей ...... главное все взаимозаменяемые и параметрические.

[Nikona 7]

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

И кто это вам сказал что структура допустим "давноизвестного" металлореж станка заранее известна

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

оборудования

Плавали... знаем

[sloter 546]

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

оборудования

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

В общем случае, когда есть прототип, тем более серийно - выпускаемое изделие, схему конструктивного членения укрупнено всё же можно сформировать. Ну а вплоть до деталей конечно же нет.

[Nikona 7]

И это действительно особенность подхода

С которой сталкивается каждый разработчик изделия сложнее табуретки

.... хотя и у неё не всегда заранее известно кол-во ножек

[sloter 546]

С которой сталкивается каждый разработчик изделия сложнее табуретки

Ну да! Ruslan я думаю не табуретки проектирует. Однако большую часть по полочкам раскладывает.

[Ruslan 266]

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

Первая цифра 0-2 изделия, комплекты, и пр. 3-6 сборки, 7-9 детали.

Когда концепция присвоения имен определена (формализована), автоматизировать не проблема. Гланое его выработать, если ГОСТовский не устраивает (клаччификатор).

sloter

Разбить на функциональные блоки можно практически любое изделие, даже новое. Ведь заранее известны входные и выходные данные.

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

Ну да! Ruslan я думаю не табуретки проектирует. Однако большую часть по полочкам раскладывает.

Это не секрет. Оптические приборы, конкретнее прицелы и приборы наблюдения и целеуказания различных категорий.

[sloter 546]

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

В том то и дело, что количество этих чёрных ящиков у нас в процессе проектирования постоянно меняется.

Оптические приборы, конкретнее прицелы и приборы наблюдения и целеуказания различных категорий.

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

[Ruslan 266]

В том то и дело, что количество этих чёрных ящиков у нас в процессе проектирования постоянно меняется.

Одного уровня или очередной черный ящик разбивается на несколько меньших?

Если одного уровня это уже изменение ТЗ, но разве это проблема добавить еще один номер при появлении такого узла?

[VOleg 228]

А я думаю, что это дым и компа валит?

Во рейтинг у темы! Неужели все так плохо? Школа нужна, школа.

Хорошо хоть юмор стали понимать и улыбаться.

Что-то я не все, перечисленные Leon, ГОСТы нашел. Только первый и в неудобном форме.

[sloter 546]

Одного уровня или очередной черный ящик разбивается на несколько меньших?

Одного уровня, так как это самый тяжёлый случай. Другие полегче.

но разве это проблема добавить еще один номер при появлении такого узла?

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

[Ruslan 266]

Некоторые добавить, другие выкинуть. И так на протяжении всего процесса проектирования. Это и есть постоянное изменение структуры.

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

Про выкидывание, то в процессе проектирования изделия я их сразу не выкидываю, а то вдруг снова станут нужны.

[sloter 546]

Добавление новых функций, это новый номер и новая модель.

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

Не думаю, что проще переделывать созданные детали под другие функции, проще создать.

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

в процессе проектирования изделия я их сразу не выкидываю, а то вдруг снова станут нужны.

Я имел ввиду выкинуть из сборки. С диска я их конечно не удаляю.

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

Это уже off-top конечно. Отдельная большая тема.