В АО "Промышленные технологии", г. Северодвинск, требуются инженеры-конструкторы (механики, проектировщики металлоконструкций). Подробнее о проектах компании см. на сайте [URL=https://prom-tech.pro/]https://prom-tech.pro/[/URL]

[B]Опыт работы: от трех лет[/B]

Полная, частичная занятость, [B]удаленный режим работы[/B].

[B]Обязанности:[/B]

Разработка КД согласно ЕСКД в приложениях, разработанных под комплекс T-FLEX;

Разработка металлоконструкций и различных механизмов;

Выполнение и оформление расчетов;

Работа с поставщиками оборудования;

[B]Требования:[/B]

Образование - высшее техническое;

Способность и готовность к освоению новых программных профильных продуктов;

[B]Знание ЕСКД;[/B]

Опыт разработки механизмов;

Умение работать в команде.

[B]Будет плюсом:[/B]

Знание T-FLEX CAD;

Готовность пройти бесплатное обучение (в т.ч. on-line) работе в T-FLEX CAD и комплексе приложений ASTRA, разработанных под программы системы T-FLEX

;

Примечание: Astra.CAD - плагин под T-FLEX CAD, выполняющий в фоновом режиме отправку данных в T-FLEX DOCs (знание T-FLEX DOCs не требуется, работа с плагином мало отличается от работы в классическом T-FLEX CAD)
 .

Мне одному режет глаз названия T-FLEX PLM и Лоцман PLM?
Маркетологи как всегда пускают пыль в глаза. Что такое настоящее PLM продемонстрировано [URL=https://www.atomic-energy.ru/news/2022/07/04/126106]здесь[/URL]. Понятно, что и DOCs и Лоцман - это PDM системы и до PLM им еще очень далеко. Не хватает самой важной части - ERP. Без этой части никакого жизненного цикла вы не получите.
Мы как раз внедрили на нашем предприятии PLM-решение, поэтому знаю о чем пишу: примерно тот же набор модулей, что и на слайде по приведенной выше ссылке. Если САРУС.PLM - это не просто маркетинговый лозунг, то выглядит он гораздо привлекательнее, т.к. интеграция PDM-ERP совсем нетривиальная задача и бесшовной такая интеграция не бывает.

[QUOTE] написал:
Есть 3D деталь в ней (в файле) прорисованы чертёжные виды, затем эта деталь устанавливается в сборку (в другой файл - общий). Далее для общего оформления требуется получить чертёж всех деталей, почему нельзя сделать получение чертёжного вида напрямую из выбранных 3D деталей с уже заданными параметрами, а приходится создавать независимый фрагмент с повторной установкой параметров? Так можно запутаться повторно вводить параметры в каждую деталь, просто сделайте функцию - получить чертёжные фрагменты из текущей деталиСпасибо за понимание![/QUOTE]
Ну, Вам стоит обратиться к справке. Этой функции уже лет 20. Просто создайте вектор привязки в 2D окне вашего 3D фрагмента, положите на слой линии изображения вида, свяжите вектор привязки со слоем. Потом в сборке у 3D фрагмента установите параметр показывающий 2D и разместите по вектору привязки в нужное место на чертеже. В более ранних версиях это работало примерно так, сейчас нужно проверять. Удачи.

[QUOTE] написал:
T-FLEX CAD - это другая, и более длительная история. Но мы по этой теме тоже активно работаем. Но T-FLEX CAD уже сейчас вполне прилично работает на Linux с использованием Wine.[/QUOTE]
Спасибо за ответ, Сергей Юрьевич.
Но, как Вы понимаете нас не интересует отдельно DOCs и отдельно CAD. Все это осталось в далеком прошлом. Отдельно CAD это вообще для вымирающего вида проектантов.
Как происходит интеграция DOCs, работающего в Astra Linux и CAD под Wine? Если правильно понимаю, так же как и в случае CAD под Windows и DOCs под Linux, через сервер приложений и через порты.
Т.е. в этом случае все наши плагины под CAD и отдельные приложения, использующие связку CAD-DOCs продолжат работать под эмулятором штатно.
Приложения для нормировщиков, архива возможно тоже будет под запускать под эмулятором, а вот обмен с ERP скорее всего придется переписывать, т.к. там весьма критична скорость передачи данных.
В 17 версии макросы можно разрабатывать в VS, запускающейся из редактора. Какая среда разработки будет запускаться в случае работы под Linux?

[QUOTE] написал:
2. Если будет интеграция, то она ожидается гораздо более глубокой, чем просто на уровне ядра.[/QUOTE]
Сергей Юрьевич, подскажите пожалуйста, насколько предполагается уровень развития API в этой системе и какие языки предполагается использовать под PDM и CAD?
Вообще общероссийской системы мы ожидали с 2008 года, наблюдая зоопарк систем. Не дождавшись, начали разрабатывать под свои задачи модули на API T-FLEX DOCs и T-FLEX CAD. Теперь ситуация начала быстро меняться и не за горами команда всем переходить на ASTRA Linux, а то и круче - на отечественную PLM-платформу под ASTRA Linux.
Если с перекачкой данных из одной PLM в другую понятно, то с модулями - нет. Получается, что наши наработки полетят в корзину? Понятно, что все не зря - отработана технология. Но меня волнует вопрос о возможности повторной разработки под САРУС или там все закрыто - наподобие коробочной поставки?
На мой взгляд, идея Гербария, была классной, по аналогу с ПО Apple: любой желающий разработчик, прошедший сертификацию, мог предложить свое ПО.

Ух, ребята! Прям завидую вам всем. У вас такие проблемы.... настройки, бантики, фишечки, шаблончики.

Сталкивался с подобным при прорисовке нижней плиты вырубного штампа, тоже по ГОСТ. Все дело в групповых чертежах, параметры исполнений которых представлены в табличной форме: может ошибиться конструктор, технолог и рабочий. ЕСКД допускает два варианта: таблица параметров исполнений либо отдельные листы исполнений. На мой взгляд второй вариант предпочтительней для всех перечисленных категорий. Работая в мощной параметрической системе и формировать таблицу исполнений, на мой взгляд очень странно. Таблицу исполнений нужно формировать потом автоматически в виде отчета.

У нас закуплена Норма CS. Вся нормативка актуальная.

Согласен. Это отдел оснастки. Варяться в собственном соку пока. Хотя, подходят ответственно, аккуратно. Они давно так работают. Раньше вообще на пользовательской машине все библиотеки хранились, а проекты по локальным. Когда пришел, настроил сервер, все проекты и библиотеки перенес на него. Делаю бэкап периодически. Кроме конструкторов и админов доступа на запись нет ни у кого. Так что того, кто накосячил вычислим быстро. Технологи, нормировщики, планировщики уже работают в доксе, следующими буду переводить в докс конструкторов оснастки.

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

[QUOTE]Тимофей Рукосуев написал:
Практически не проходит недели, когда мне приходится делать это. Обрабатываемая в оснастке деталь, установленные в сварочной оснастке заготовки, конус шлифовального станка совместно с планшайбой и хомутом... В ЕСКД все это названо обобщающим: “Обстановка”. [/QUOTE]
Поддерживаю. Более того, предлагал это сделать еще в 9 или 10 версии, писал предложения в техподдержку, когда работал конструктором оснастки.[QUOTE]vite написал:
В идеале механизм отрисовки деталей должен быть завязан на определенный класс прототипа по классификатору из общей базы данных системы. Если, к примеру, одна и та же деталь используется при построении оснастки и изделия, то глобально это можно переопределить при вставке в сборку или в параметрах фрагмента. То есть, все что понадобится -- это добавить определение класса стилей прототипа. В текущей реализации уже существует механизм классификации прототипов для генерации спецификации (например, раздел: Спецификации\Детали). Тоже самое нужно сделать для определения глобальных стилей (  схема  ).[/QUOTE]
Отличный вариант.

[QUOTE]student92 student92 написал:
Но в моём случае работа происходит на доксе 2012, есть ли возможность под эту версию адаптировать?[/QUOTE]
Вот Вас торкнуло! Подойдите к руководителю и попросите сделать апгрейд, хотя бы до 15 версии.

[QUOTE]Шурик написал:
Ну это не я представляю, а  Engineer , вопрос задал, а так в раме вилочного погрузчика всего 12 типов швов. Швы различаются не только типом соединения, но и катетом, типом соединения (сплошной, прерывистый...) наворотить можно много чего, особенно на спецтехнике. Но вот сварной шов на рисунке к какому типу соединения отнести (?) сверху стыковой, на радиусе нестандартный, на боковой поверхности тавровый, честно скажу - ГОСТы не штудировал. Поэтому  поступаю просто, где большая длина, такой и шов, скорее всего я неправ?

Прикрепленные файлы
Захват-43.jpg  (39.97 КБ)[/QUOTE]
Просто голову нужно включать. Это не сварное соединение, а колхоз. Сделайте разделку под профиль, чтобы остались только стыковые и тавровый шов и будет вам счастье.

А почему Вы пишете свои предложения и замечания по системе на форуме, а не направляете в техническую поддержку? При этом возмущаетесь, что Ваши посты обсуждаются. От тех. поддержки всегда есть обратная связь. Сам, если обнаруживаю ошибки пишу на [URL=mailto:support@topsystems.ru]support@topsystems.ru[/URL] и в течение трех рабочих дней получаю ответ.

Замечание принял, ответил Вам в личку.

Как говориться: На вкус и цвет товарищей нет. По мне так слишком пестро. Достаточно бы двух-трех цветов: черный - форматка, синий размеры и темно-красный текст.
Как правильно заметил Шурик, Вам мешает излишняя категоричность. ЕСКД для меня - рекомендации, которых лучше придерживаться, чтобы инженеры и рабочие понимали друг друга правильно. Но молиться на ЕСКД не стану. Если где-то ЕСКД попросту не успевает за прогрессом, что с ним случается иногда, то рекомендации можно и проигнорировать, если это не приведет к браку.

Речь не о длине и ширине листа, а о его толщине.
Это до тех пор, пока предприятие не внедрило полностью PDM и ERP системы. После начала промышленной эксплуатации указанных систем, руководство предприятия очень быстро подберет аргументы таким посылающим. Потому как увидит, где можно сэкономить время, а соответственно деньги.
Да, ЕСКД облегчило труд конструкторов, проектирующих на кульмане. Стандарты были нацелены на сокращение времени конструкторско-технологической подготовки производства (КТПП) при бумажной КД. Но те времена давно ушли. Сейчас ЕСКД, порой, тормозит КТПП. Та же ситуация и с групповыми чертежами, когда выбран табличный вариант выполнения, а не отдельными документами (ЕСКД предлагает два варианта). При запуске PDM табличные чертежи канут в лето, останется только второй вариант. Кстати будет меньше ошибок как у конструкторов, так и у технологов, нормировщиков и рабочих.

Вот именно, что допускается. При этом стандарт требует полного обозначения сортамента в конструктивной структуре изделия (КСИ). А когда конструктор проектирует в связке CAD-PDM, он несет ответственность за КСИ. Какой смысл в чертеже писать сокращенно, а потом в КСИ указывать сортамент, если можно сразу выбрать в справочнике полное обозначение, которое система автоматом запишет в КСИ?

8.5 лет отработал в КБ (основной проектант), флэшки отрубили почти сразу и доступ к дискам тоже. На диске С на запись только папка Temp с ограниченным объемом, а логические просто скрыли. Вся работа в сетевой системе и на сервере.
Скоро будете в чертежах указывать полное обозначение сортамента, вместо привычной Ст3 380-2005, чтобы ОМТС без лишнего согласования готовило закупку, потому как сейчас в тренде - все с колес с минимальным запасом на складе - так же как и за бугром: на складе двухнедельный запас.

Некоторые Ваши предложения мне нравятся. Например с крюком. Все четко.
Конкретно это - считаю излишеством. У самого когда-то был шаблон документа, где выноски и размеры синего цвета, а остальной текст - бордового. Но изменять отдельно цвет элементов в тех. требованиях, думаю уже перебор.
Опять же все эти цветовые решения актуальны только для работы исключительно в кад, без докса или другой PDM-системы, потому как сам начертил - сам отправил на печать, в настройках печати указал параметр "Одноцветный".
Но все меняется, когда начинается проектирование под управлением PDM-системы. Конструктору будет уже не доступен плоттер, доступен только электронный журнал заявок печати документов. Экспорт в PDF также недоступен, т.к. он выполняется автоматически при сдачи GRB-файла на сервер. Проектирование становится более формализованным, пункты ТТ и материалы выбираются из справочников, согласование чертежей электронное. Цветное изображение в PDF-документах запрещают военпреды, как это ни печально.
То, что в ближайшие годы PDM-системы будут такими же привычными как Проводник Windows не вызывает сомнения. Слишком много плюсов для предприятия и жалобы конструкторов на незначительные неудобства будут просто игнорироваться. Более того, все USB-порты будут заблокированы и права на установку программ отключены. Камеры во всех углах и мониторинг экранов пользователей уже никого не удивляют.