Перейти к публикации

Оформление чертежей Solidworks


Рекомендованные сообщения

Leon Просвяти меня безграмотного, что это за свойства и как их будет видно.

<{POST_SNAPBACK}>

Не наговаривай на себя, желающие и так найдутся

post-2822-1158828051_thumb.png

post-2822-1158828114_thumb.png

post-2822-1158828403_thumb.png

post-2822-1158828418_thumb.png

post-2822-1158828435_thumb.png

Ссылка на сообщение
Поделиться на других сайтах


или ты прописываешь обозначение и в свойствах и в имени файла?

Именно
Ссылка на сообщение
Поделиться на других сайтах

От куда этой вложенности взяться?

<{POST_SNAPBACK}>

У нас только часть изделий "по классификатору", а в основном - "предыдущая" система с иерархическим принципом образования обозначения. (Кстати старую систему считаю удобнее на порядки для мелкосерийного и индивидуального производства, т.к. сразу видно из какого узла деталь, а классификатор этот - очевидный подарок вражеской разведке. "Ищи, кому выгодно" - помните школьную латынь?)

Структура папок у меня повторяет структуру изделия (впрочем и в децимальной системе тоже) и глубина вложенности 6-7-8 реальна. Плоский вид ("все в одной куче") - неудобен уже при сотнях деталей в изделии. Будет не работа, а сплошной скроллинг (т.е. мышкомучанье). Да и винда загибается на очень больших папках. Для маленьких изделий - да, возможный вариант.

2Kelny

Переименовываются ли файлы при сдаче? Как решается коллизия, возникающая оттого, что в файлах солида прописан полный путь? Т.е. архивная сборка в общем случае не откроется, а начнет спрашивать куда дели ее детали? Если не переименовывать (что логично вроде), то как гарантируется, что открывается файл из нужной папки? ...

<{POST_SNAPBACK}>

Ссылка на сообщение
Поделиться на других сайтах

...а классификатор этот - очевидный подарок вражеской разведке. "Ищи, кому выгодно" - помните школьную латынь?

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

Можно ли об этом поподробнее?

<{POST_SNAPBACK}>

Самая большая горечь в том, что тем самым уже сами себе зарезали дорогу к эффективному применению SW Explorer.

Как известно, эта прога позволяет создавать копию проекта с сохранением всех ассоциативных связей и автоматической заменой выбранной комбинации символов в названии файлов на другую. Например: было АБВГ.00.01.NNN а переделалось в 7СИ-23.01.04.NNN. Очень и очень полезная процедура, особенно если идёт полнокровное проектирование сложного изделия: НИР-ОКР-серия-модернизация и т.д. Если предложенное

Так а если в свойство Обозначение вбить $PRP:"SW-File Name" ?

<{POST_SNAPBACK}>

сработает (неприменно завтра проверю) то это самое обозначение насквозь проскочит от модели до чертежа и это будет просто здорово, именно такой возможности мы уже много лет требуем от SWR и никак не получим желаемого.

Однако сотни пользователей уже имеют ЗАКОННОЕ основание обзывать свои творения каким ни будь АБВГ.00.01.NNN Бутылка и железный повод в эту самую бутылку залезть.

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

Что называется не проявив должной твёрдости в начале далее придётся пролить крови не в пример более.

Может есть возможность оторвать конец темы и под именем "электронный документооборот" или еще как - оформить отдельной темой?

<{POST_SNAPBACK}>

Есть такая тема, в разделе про PDM.

Например

http://fsapr2000.ru/index.php?showtopic=12418

Ссылка на сообщение
Поделиться на других сайтах

если идёт полнокровное проектирование сложного изделия: НИР-ОКР-серия-модернизация и т.д.

<{POST_SNAPBACK}>

Ну это специфика производства. У меня сейчас почти все оригинальное идет, несерийное производство и преемственность хромает. Но: если работать с обозначениями "по классификатору" - обезличенность обозначний не требует массовых переименований. Я массовые переименования делаю TotalCommander'ом, потом открываю сборку и на вопросы указываю новые детали. Возможно это менее быстро, но не настолько, чтобы отказываться от чего-то. Кстати у Вас при массовом переименовании Втулка тоже останется Втулкой :doh: . Так что - переименование - не аргумент.

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

<{POST_SNAPBACK}>

Сработает. Удобная переменная, быстро привыкаешь. У меня в в шаблоне детали "Обозначение" = $PRP:"SW-File Name" (чтоб клетка не пустая, потом правлю вручную), а в чертеже "Обозначение" = $PRPSHEET:"Обозначение" (это правлю только для редких типов ГЧ и т.п., а СБ, МЧ, и детали - не правлю). В штампе отображается $PRP:"Обозначение", т.е. свойство чертежа. И даже через такую цепочку проскакивает на ура. В отсоединенных чертежах пару лет глючило без модели, но сейчас вроде наладили.

...при хорошо организованном компьютерном поиске...

<{POST_SNAPBACK}>

Да да... Без компьютера никуда, в цеху любой вопрос решить - звонишь туда, где он есть. По моему такая система удобнее всего технологам большого завода при серийном производстве или конструкторам при работе в стиле "возьмем каталоги и поиграем в лего". Систему как таковую я не отрицаю (в рамках предприятия), но иметь ЕДИНУЮ НА ВСЮ СТРАНУ систему в капиталистическую эпоху - смешно. Причем именно на оборонку давят и заставляют на нее переходить (кого знаю - уже перешли и мало кто рад.). Я не технолог и не большого завода и каталогов нет, отсюда и мое мнение. Оно - для моих условий :smile: . Изменено пользователем ber2004
Ссылка на сообщение
Поделиться на других сайтах

Кстати у Вас при массовом переименовании Втулка тоже останется Втулкой. Так что - переименование - не аргумент.

<{POST_SNAPBACK}>

Но в чертёж то и спецификацию этот атрибут должен пройти как АБВГД.00.00.NNN, а не как АБВГД.00.00.NNN Бутылка. Есть строка для АБВГД.00.00.NNN и есть строка для Бутылка.

Во все ссылки у нас уходят именно атрибуты, так и все шаблоны настроены.

Кстати, именно атрибуты считываются и PDM системами.

Сработает. Удобная переменная, быстро привыкаешь. У меня в в шаблоне детали "Обозначение" = $PRP:"SW-File Name" (чтоб клетка не пустая, потом правлю вручную),

<{POST_SNAPBACK}>

Интересно, почему нам этого не подсказали товарищи из SWR?

Если всё так просто, то прям странно....

Ссылка на сообщение
Поделиться на других сайтах

Но в чертёж то и спецификацию этот атрибут должен пройти как АБВГД.00.00.NNN, а не как АБВГД.00.00.NNN Бутылка.

<{POST_SNAPBACK}>

Макрос, который то, что до первого пробела пишет в свойство "обозначение", а то, что после (исключая сам пробел) - в "наименование". Сам бы от такого не отказался. Было бы что куда копировать, а скопировать наверное можно...

почему нам этого не подсказали товарищи из SWR

<{POST_SNAPBACK}>

Потому что для ИХ работы ЭТОГО не надо... За чужим дитём...э-э... менее пристально смотришь :-)

Но наверное дело в том, что в хэлпе в общем списке переменных этой нет (и наверное многих других тоже). Я вот на нее случайно наткнулся после многолетних поисков.

Может в материалах по API кто видел более полный список переменных? Может ещё что вкусное найдем, на уровне <stack>?

Ссылка на сообщение
Поделиться на других сайтах

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

Макрос, который то, что до первого пробела пишет в свойство "обозначение", а то, что после (исключая сам пробел) - в "наименование".

<{POST_SNAPBACK}>

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

А если в обозначении присутствует еще пробел.

<{POST_SNAPBACK}>

Все пробелы кроме первого переносятся в наименование (напр. "Колесо зубчатое"). А первый пробел - можно использовать как разделитель, т.к. обозначение всегда слитно. (СБ, ГЧ и т.п. по ЕСКД пишутся слитно, хотя и не все это знают :bleh: )

Во время проектирования, они могут изменить наименование...

<{POST_SNAPBACK}>

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

Цитата

или ты прописываешь обозначение и в свойствах и в имени файла?

Именно

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

Ссылка на сообщение
Поделиться на других сайтах

в хэлпе в общем списке переменных этой нет (и наверное многих других тоже)

<{POST_SNAPBACK}>

Выдержка из справки SW 2005

Все документы SolidWorks имеют эти свойства, определяемые системой:

SW-Автор Поле Автор в диалоговом окне Суммарная информация

SW-Заметки Поле Заметки в диалоговом окне Суммарная информация

SW-Имя конфигурации Имя конфигурации в ConfigurationManager (Менеджере конфигурации) детали или сборки

SW-Создано * Поле Создано в диалоговом окне Суммарная информация

SW- Имя файла имя документа, без расширения

SW-Имя папки папка документа с обратным слешем в конце

SW-Ключевые слова Поле Ключевые слова в диалоговом окне Суммарная информация

SW-Кем сохранено Поле Кем сохранено в диалоговом окне Суммарная информация

SW-Сохранено * Поле Изменен в диалоговом окне Суммарная информация

SW-Дата, длинный вариант * текущая дата в длинном формате

SW-Дата, короткий вариант * текущая дата в коротком формате

SW-Предмет Поле Предмет в диалоговом окне Суммарная информация

SW-Оглавление Поле Оглавление в диалоговом окне Суммарная информация

* Свойства, которые включают форматы дат, зависят от языка и региона. Для получения дополнительной информации см. настройки Панели управления на компьютере.

Кроме того, чертежи имеют следующие свойства, определяемые системой.

SW - Текущий лист номер активного листа

SW-Размер основной надписи размер листа в формате активного листа

SW-Имя листа имя активного листа

SW - Масштаб листа масштаб активного листа

SW-Размер шаблона размер шаблона чертежа

SW - Количество листов общее число листов в активном документе чертежа

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

Да даже если вы откроете один из шаблонов основных надписей, что идут вместе с солидом то вы увидете, что он весь нашпигован этими полями свойств, и $PRP:"SW-File Name" там тоже есть

Ссылка на сообщение
Поделиться на других сайтах

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

Не забудешь, когда генеришь спецификацию. Пробелы видны сразу.

Кроме того это хорошее, надежное средство самопроверки.

Окончательные имена, да и обозначения присваиваю после формирования облика изделия и регистрации в нашей системе. (в нашей конторе принята децимальная система по классификатору; на предыдущей была своя система артикулов, котрые надо было регистрировать в системе типа ERP/MRP).

Поэтому ничего не забудешь. А забудешь - не сделают.

Ссылка на сообщение
Поделиться на других сайтах

В английском варианте справки почему то этого нет

<{POST_SNAPBACK}>

Там и искал... Конечно не секрет, когда знаешь где искать :-)

Не забудешь, когда генеришь спецификацию. Пробелы видны сразу

<{POST_SNAPBACK}>

У меня в SW-спецификации (в чертеже сборки, но за рамкой) столбец $PRP:"SW-File Name" и рядом $PRP:"Обозначение". Несоответствия заметны быстро.
Ссылка на сообщение
Поделиться на других сайтах

Короче нет в этом секрета.

Да даже если вы откроете один из шаблонов основных надписей, что идут вместе с солидом то вы увидете, что он весь нашпигован этими полями свойств, и $PRP:"SW-File Name" там тоже есть

<{POST_SNAPBACK}>

Вот то и странно.

В прочем, чего греха таить, обучавшиеся во времена SolidWorks 2001+ очень редко штудируют help от SolidWorks 2005. В том числе и в IT подразделениях. Слишком частая смена версий имеет и отрицательную сторону то бишь. Вот если человеку начинает не хватать его навыков, то он начинает копать глубже, в том числе и в интернете.

Там и искал... Конечно не секрет, когда знаешь где искать :-)

<{POST_SNAPBACK}>

Вот именно, главное знать что искать.

Теперь вот что: проверил сегодня предложенное $PRP:"SW-File Name" - сработало как надо. Сработало и преименование, и копирование, и копирование с заменой, через SolidWorks Explorer. В том числе, автообновились строки "Обозначение" в чертежах. Спасибо большое.

Таким образом, проблема переименования крупных проектов сильно теряет свою остроту, хотя вся рутина не убивается всё равно. Ведь не всегда АБВГ.01.NNN заменится на ДЕЖЗ.01.NNN, но может быть любое сочетание QWER.NN.MMM. Пожалуй, таки придётся писать ТЗ на некую внешнюю программу реализующую всем известную таблицу соответствия новых индексов и старых, с последовательным автоматическим многократным запуском SolidWorks Explorer.

P.S. Посмотрев работу через SolidWorks Explorer при условии применения $PRP:"SW-File Name" сотрудники IT одела - соавторы нашего СТП очень сожалели о том, что пошли на поводу у отдельных товарищей и согласились добавлять в название файла "наименование", а так же СБ, ГЧ и прочее.

Что называется, лучше поздно чем никогда.

Ссылка на сообщение
Поделиться на других сайтах

соавторы нашего СТП очень сожалели о том, что пошли на поводу у отдельных товарищей и согласились добавлять в название файла "наименование", а так же СБ, ГЧ и прочее.

<{POST_SNAPBACK}>

Ну и где логика? ИМХО пользовать только имя файла и не пользовать атрибутов (свойств) его - достойно эпохи ДОСа. Атрибуты Ваше небольшое предприятие активно пользует, так? Пусть среди них будут "Обозначение" и "Наименование". (А наверное есть уже, иначе PDM не работает, так?). И любая программа от Проводника Windows и до ... может с ними работать. Чего на имени файла циклиться?

В конце концов, представьте себе мир, в котором в чертежах не указывается наименование, только обозначение. Можно так жить? Можно!!! Но на эскизе от руки будет имя "Втулка, 5 шт., Сталь45", и очень редко номер. Люди выбрали систему в которой наряду с уникальным идентификатором есть неуникальное имя. И гнилой Запад, и мы и Азия... ЛЮДЯМ ТАК УДОБНЕЕ!!! Это не баг, это фича!! :doh: Это свойство человека. Естественно, везде где действует закон больших чисел, есть сторонники и других вариантов, но можно вспомнить и "вся рота шагает не в ногу, один поручик в ногу" :smile: . Я не скрываю, что пользую "длинное" имя, потому что удобнее лично мне, но, согласитесь, приятно когда большинство с тобой солидарно.

$PRP:"SW-File Name" - сработало как надо.

<{POST_SNAPBACK}>

Попробуйте в то же место штампа чертежа вставить $PRP:"Обозначение" (или ваш синоним для него, оно же уже заполнено для PDM или из PDM?). Обнаружите, что это тоже работает, в штампе появится искомый текст. :smile: . Это тоже удобно. Но при этом еще и более правильно, чтобы в штампе и в базе данных информация (т.е. обозначение документа) была идентична. :wink:. А имя файла в базе не обрабатывается обычно никак, а в "приличных" еще и шифруется, чтобы враги не украли. И спор об имени становится беспредметным. Меня-то имя файла волнует потому, что я хочу работать без PDM в нашей небольшой конторке. Изменено пользователем ber2004
Ссылка на сообщение
Поделиться на других сайтах

Ну и где логика? ИМХО пользовать только имя файла и не пользовать атрибутов (свойств) его - достойно эпохи ДОСа. Атрибуты Ваше небольшое предприятие активно пользует, так? Пусть среди них будут "Обозначение" и "Наименование". (А наверное есть уже, иначе PDM не работает, так?). И любая программа от Проводника Windows и до ... может с ними работать. Чего на имени файла циклиться?

<{POST_SNAPBACK}>

Более длинное название - больше и ошибок. :thumbdown:

Когда совместно работает много (несколько сотен) инженеров очень важно что бы всё было понятно всем. Даже тем, кто собственно в проектом ещё мало знаком.

Начинается всё обычно именно со временных названий, из серии "007пиджак", "010державка" и т.п. пока всё ограничивается 3...4 компьютерами ещё куда ни шло, хотя и тут бывают неприятности, особенно там где механика граничит с электрикой. Но вот когда выходим на уровень нескольких конструкторских отделов в связке, т е на отсеки или общую сборку, то модели часто просто "взрываются", даже если это всего навсего на 1200....1500 компонентов и 8...10 уровней вложенности. :surrender:

То есть первое дело - это добиться уникальности названия каждого файла в сборке, ничего лучшего чем присвоить имени модели значение "обозначения" (если угодно то и вместе с "наименованием") по схеме деления тут не придумаешь. :wink:

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

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

Всё это тоже нужно каждый раз забивать руками, при этом самыми золотыми руками и самыми светлыми головами. Если ограничиться только свойством "обозначение" оставив прежним имя файла, то получается такая тарабарщина что и сам разработчик через год ничего не поймёт, проверено не однажды. :wallbash:

Спрашивается: как эту процедуру упростить, да ещё и контексты не терять? Ответ прост - использовать SW Explorer, только надо исхитриться завязать во едино название модели и её свойство "обозначение". Именно этот путь даёт наибольший выигрыш, по крайней мере как видится сейчас.

Если кто предложит лучше - буду только рад.

Попробуйте в то же место вставить $PRP:"Обозначение". Обнаружите, что это тоже работает . Это тоже удобно. Но при этом еще и правильно.

<{POST_SNAPBACK}>

Присвоить Обозначению значение Обозначения??

Что то я не очень понял, поясните пожалуйста ещё раз.

Изменено пользователем Странник
Ссылка на сообщение
Поделиться на других сайтах

Давайте сначала о том, в чем мы согласны:

1. Мы хотим, чтобы вводить руками любую инфу ОДИН раз и чтобы она потом размножалась по докумантам автоматически

2. Чтобы в файле был полный набор атрибутов (и в модели и в чертеже и в спецификации и проч. типах)

3. Чтобы все файлы были учтены по этим атрибутам в базе данных.

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

5. Один раз (п.1) не получается ввиду итеративности процесса, ослабляем условие до одного раза на итерацию.

---

Дальше РАЗВИЛКА. Можно

1. забить инфу в свойства, а простенькая прога перенесет ее в имя файла, а можно

2. забить в имя файла, и простенькая прога (другая) перенесет инфу в свойства.

---

Из сложного простое легко сделать, а из простого сложное - никогда. Т.к. диалог свойств явно СЛОЖНЕЕ диалога переименования, я предпочитаю инфу вводить в свойства модели (в основном) и изредка чертежей (Материал в свойства автоматом попадает из переменной "SW-Material@Part1.SLDPRT", масса аналогично). Оттуда они автоматом идут в штамп, и в спецификацию, и в PDM. Предпочтение инстинктивное, у меня ТАКОЕ представление о гармонии мира и втором начале термодинамики (когда процесс от сложного к простому (рост энтропии) - естественный). В таких вещах трудно уговорить, можно только рассказать о своем видении... Я ведь не уговариваю, и Вы правы тоже (по своему), просто все многогранно и можно с разных сторон посмотреть. Счастливы двуглазые... :smile:

Итого:

0. Программу по-любому писать :sad::doh:

1. по обоим вариантам нажимать кнопок одинаково раз,

2. по 1-му мы работаем с инфой, которая в базу уйдет (из свойств), непосредственно, по 2-му через посредника в виде программки упомянутой (эх, написал бы кто...). Напрямую кошернее :smile:

3. по 1-му Мы в одном диалоге все делаем, а по 2-му имя файлу давать в одном, а потом в свойства все равно лезть примечание вставить, "Разработал" и проч...(черт, все-таки по 2-му больше кликов)

4. Человеку голого номера все-таки мало (см. цитату), а ящику все равно, он и с именем прожует.

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

Спрашивается: как эту процедуру упростить,

<{POST_SNAPBACK}>

---

ИТОГО2: По-любому нужна программка для переноса инфы (по вар.1, или по вар.2). Я бы:

1. программерам заказал программку для удобного массового задания свойств файлов сразу у всех деталей сборки (табличный интерфейс, средства автоподстановки, массового переименования по маске и проч.). Оптимально - плагин к TotalCommander'у. Для тегов mp3 там уже плагин есть, что мы с солидом рыжие что ли? И написать легче, почти весь функционал в Тотале (6.5 и выше) есть. И недорого.

2. в шаблонах чертежей и моделей забил бы все поля (чтобы программу не надо было грузить по мелочам: свойством масса или материал и т.п. Быстрее будет)

3. В программе добавил бы волшебную кнопку "переименовать файлы по маске" по инфе из свойств и с отслеживанием связей (like Explorer в пределах указанной папки, вплоть до всего архива).

4. Изыскал бы возможности, чтобы при перемене свойств Обозначение и Наименование (и любых других, что разрешены для маски, а по логике - именно ЛЮБЫХ) - происходило переименование файла (с отслеживанием связей). Если свойства редактировать в этой проге - можно настройку сделать фонового автопереименования, но ведь в свойства и прямо в солиде залезть можно...Впрочем тут подмену надо сделать, чтобы по соотв. пункту меню вызывался не родной диалог, а своя прога (типа защита от дурака и - гарантия переименования).

5. Соорудил бы (заказал) анализатор геометрии, чтобы код по классификатору автоматом подставлял

6. Соорудил бы приблуду к PDM, для резервирования очередного номера детали (код уже выше получен)

7. Настроил бы программу на проигрывание траурного марша и заказ столика по достижении номера детали 999. По ЕСКД жизнь на этом остановиться должна. "Поубивал бы" (из анекдота).

---

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

А что, ваших программеров действительно напрячь можно? Я готов поучаствовать в ТЗ ;-)

Ссылка на сообщение
Поделиться на других сайтах

P.S. А вообще по именам файлов все запущенней гораздо. Когда я говорил, что применяю "длинные" имена - я приукрашивал. На самом деле, т.к. ...

Если ограничиться только обозначением, то получается такая тарабарщина что и сам разработчик через год ничего не поймёт...

<{POST_SNAPBACK}>

... я часто применяю "очень длинные", типа АБВГ.123456.000 Уголок левый верхний (но свойство "Наименование"=Уголок, и в штампе - Уголок)

(Маска переименования для упомянутой проги: <Обозначение>пробел<Наименование>пробел<Примечание к наименованию>)

Начинается всё обычно именно со временных названий, из серии "007пиджак", "010державка"

<{POST_SNAPBACK}>

Для гарантии уникальности я такие именую по схеме: <уникальное обозначение узла>-<010державка>. Коряво, зато уникально. Мало ли державок...
Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • filsan
      Когда есть мерная фреза это хорошее решение. А когда ее нет, то в наших условиях проще модель дать, чтобы программист станков с ЧПУ имеющимся инструментом сделал обработку.  В любом случае спасибо за ответы всем откликнувшимся. 
    • gudstartup
    • advocut
      @hlibhlib т.е. нужно на каждую установку по слою и симулировать отдельно (или на ходу оно переключается)?
    • Ветерок
      Так оставьте только линию траектории и отфрезеруйте по линии. Получите желаемый результат без всяких научных построений. Зачем с трудами моделировать то, что делается как надо самим инструментом?   Надо только чтобы диаметр фрезы совпадал с шириной канавки. Если диаметр будет меньше, фокус не получится.
    • Ahito
    • Srgwell
      В sw 2023sp3. Появляются дублирующие кнопки макроса, а у некоторые становятся пустыми, только наименование остается. Например . Здесь лишние дубляжи появились. Причем все рабочие. После удаления одного из них другой дубликат оказывается пустой, только наименование. Если меняю свойства кнопки одного, другой дубликат тоже меняется. После выхода из настроек он не активен . Из 10 кнопок 3 продублированный. Хлама полно. Такая же проблема и в 2024sp2. Могу видео снять  
    • Ветерок
      Ну, так пользуйтесь этой камасутрой дальше. Пусть эта деталь будет сделана не в Крео, если результат получается лучше и проще.
    • filsan
      С этим я давеча справился: нашел хорошее видео на русском  GOLF_Sream под тем видео даже комментарий оставлял с советами, как оптимизировать построение. Я тогда больше времени потратил на составление закона закрутки спирали, чем на построение шнеков (2 шт). Их даже отфрезеровали и я их в деле увидел  Круг этот с канавкой после камтракса тоже фрезеровали, все нормально работало. Но не хочется костылями пользоваться, когда можно в одной среде все сделать. 
    • Orchestra2603
      @djtim : В целом,  с определнными упрощениями эта задачка считается на бумажке.   Если очень хочется посчитать по МКЭ, то в любом случае нужно работать с геометрией сначала. Никто не считает такие сборки "как есть". Вы получите много геморроя с построением сетки, всякие малюсенькие элементики, да еще и много локальных сингулярностей, с которами потом непонятно, что делать (на самом деле, более-менее понятно, но это отдельный разговор). Как минимум, нужно свести в оболочечным элементам это все.   Отверстия под болты с у двух соответвующих соединенных деталей я бы просто соединил бы жесктой кинематической связью. Сами болты и гайки из модели я бы викинул. Потом в соответствующих узлах можно вытащить реакции, и не несложным расчетом посмотреть выдерживают ли болты нагрузку на разрыв, срез, момент изгибающий/крутящий или их комбинацию.   Красный профиль я бы вообще балкой бы моделировал (известны же параметры сечения: момент инерции, площадь, центр тяжести и т.д.?). Я не вижу никакой особой выгоды от отлавливания всех этих загибов внутри, только очень много боли. В крайнем случае, можно просто сделать типа такой приведенный трапецивидный коробчатый профиль с внутренними перегородками, если совсем тяжело.   Контакт кронштейна со скобой... Не вижу, почему нельзя просто задать абсолютно жесткое соединение bonded.    Контакт скобы со столбом... Вот тут я вижу проблемы. Я не вижу никаких посадочных мест под скобу на трубе или других креплений с трубой, а значит весь кронштейн с фонарем можем свободно вращаться и скользить по столбу. Выглядит это не очень хорошо. Если считать контакт без трения, то в расчете вся верхняя часть просто "улетит", и расчет не получится. Можно считать как bonded (не знаю, как в Catia это называется), но это будет соответствовать приваренной к трубе скобе, а это не ваш случай (или нет?). Я бы пересмотрел ваш дизайн вообще в этой части.   Кроме этого... Вас интересвет только один расчетный случай, как на картинке? вы не рассматриваете ветер "сбоку" или какие-то комбинации расчетных случаев? Имхо, то что вы на картинке изобразили - это вероятно не самый консервативный расчетный сценарий, вполне можно себе представить случаи более опасные, чем этот.   Это вполе себе типичный расчет. В стандартных инженерным приложениях такого плана, линейно-упругого анализа должно быть достаточно. Это же не какой-то сложный производственный процесс с нелтнейностями. Если его недостаточно (пластические деформации, большие перемещения, контакты меняют статус от нагрузки) , то чаще всего это свидетельствует об ошибках при проектировании. При понимании того, что делаешь, и как работать с результатами, все получится нормально. В целом же, адекватность результатов зависит от адекватности пользователя.  
    • Ветерок
      Если протягивать по траектории, то траекторию можно построить по уравнению или начертить на плоскости и навернуть на цилиндр.   Можно распрямить поверхность цилиндра, сделать на ней канавку Офсетом и свернуть обратно, потом отсечь поверхностью с канавкой цилиндр.   Но при любом способе построения шарик будет зажиматься. Единственный вариант - протягивать именно тело цилиндрическое. Но Крео это умеет только по спирали (см выше). Поэтому вариантов нет. Здесь обсуждалась тема построения шнека для перемещения бутылки в разных системах. Крео пока не может. Это кусок спирали, который можно построить протягиванием цилиндра. Горизонтальные участки тоже строятся элементарно. Остается получить корректурную геометрию переходных участков. Вряд ли это получится сделать простыми скруглениями. но можно попробовать.
×
×
  • Создать...