Комментарии 24
всё эти задачи прекрасно решаются и без утилиты, которая может начать глючить на ровном месте в самый не подходящий момент…

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

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

про AutoCAD тоже самое говорят… но мы то знаем

Вопрос, конечно, философский. ЧП случаются. Но если страшно полагаться на код, то на алгоритмы, выполняемые вручную надеяться еще опаснее (человеческий фактор- дело такое). Остаётся только предпринимать всевозможные меры, для того чтобы минимализировать риск появления ошибок. К чему мы все, несомненно, стремимся. Все-таки норма- это стабильная работа, а не наоборот!

вскрывать чёрный ящик ещё сложнее, а со свои кодом — ты понимаешь, что происходит и сразу можно понять, что пошло не так…
Да, с одной стороны, авторская индивидуальная разработка имеет максимальные шансы соответствовать всем существующим требованиям конкретного предприятия. С другой стороны — возрастает риск возникновения внештатного поведения… Но и возможностей исправления больше. И оперативного внесения изменений.
Мы постарались сделать наш модуль управления максимально прозрачным в сценариях работы и гибким для пользовательских настроек. Более того, есть мнение, что продукт этот больше внедренческий, чем коробочный. Скажем так, универсальная платформа для организации управления настройками САПР. Но и элементы «черного ящика» в нем тоже присутствуют. Так что, насколько это удобно — решать конечно заказчику!
если падает САПР — она падает на одной машине, если сламается ваша приблуда — САПР сломается во всей организации… и всех собак спустят на САПР'вцев

Когда в AutoCAD появилось цетральное управление настройками, исправления которые делались за 5 пять минут — начали делатся за пол или целый день, потомучто пришлось писать заявки САПР'вцам в центральном офисе, в другом городе. А ещё выяснилось, что для Civil'а нужны другие настройки — это вообще затянулось на несколько дней…

Если ломается "приблуда", то всех отключают от корпмодуля и работают как обычно. А сами разбираются, что сломалось...


Но вообще самый верный путь — это сначала настроить, оттестировать, а потом вводить в промышленную эксплуатацию. Тогда и собак не надо будет спускать...

руководителю всё равно, лишь бы получить положительное заключение экспертизы и деньги от заказчика
ну не согласен… это пустая сторона стакана. Мы скорее видим полунаполненный стакан ))
Лично я готов расцеловать автора статьи и разработчиков нанокада. У нас компания не настолько большая, чтобы использовать взрослые игрушки, но уже не такая маленькая, когда каждый сам себе хозяин. Проблемы, затронутые автором статьи, вызывают у меня острую головную боль — всё прочувствовал на собственной шкуре: разный уровень подготовки пользователей, копирование наработок из предыдущих проектов, местами игнорирование здравого смысла и т.п. Обязательно попробую предложенное решение.
Ps. Еще бы ворд так обуздать…

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

Если у Вас возникают вопросы и пожелания, то кроме форума можно обратиться к обсуживающему дилеру или по линии технической поддержки nanoCAD (адрес есть в личном кабинете)!
выделить папку, доступ к которой осуществляется по FTP-протоколу. Этот способ организации хранилища позволит скрыть структуру файлов, а значит заблокирует утечку интеллектуальной собственности организации, даже теоретически устранив возможность скопировать «Стандарт предприятия» вовне.

1) а что мешает «сохранить как..» хоть шаблон, хоть полупустой файл с настроенными стилями/слоями/…?
2) что будет с чертежами полученными от субчиков? при открытии автоматом все шрифты и стили поменяются в соответствии с СТП?
1. Ничто не мешает, конечно. Но DWT шаблон — это часть процесса; важная, но не единственная. Например, DWT шаблоны могут быть в разных отделах разные — а значит надо будет ходить по всем отделам (а это уже сговор :-) ). Также корпмодуль позволяет динамично обновлять DWT шаблоны…

2. Автоматом нет. Но DWS при каждом сохранении будет говорить, что в них нарушены такие-то такие-то пункты СТП на DWG. Субчиков имеет смысл строить с помощью договоров и требований к сдаваемым материалам.
Дополню) В случае со шрифтами: nanoCAD через модуль корпоративного управления можно настроить так, чтобы настроечные файлы были доступны сразу из нескольких источников: и папка созданная модулем (папка рабочей группы), и стандартные папки, и общая папка. Плюс: есть порядок очередности просмотра источников. Ну и стили управления, о которых говорилось в статье.
Иными словами, инструмент достаточно гибкий, чтобы в зависимости от ситуации получать от САПР желаемый результат. Главный вопрос — какой результат является желаемым при работе с файлами, пришедшими от субподрядчиков?
т.е. вы предлагаете в договоре с субчиками прописывать использование слоёв/типов линий/шрифта/…?
У субчиков своё ПО(возможно отличное от заказчика), своё СТП…
В одной конторе все размеры/выноски вынесены на один слой, а в другой организации слоёв с размерами может быть множество (речь про ПГС)
да, смысл в том, чтобы субчики работали по стандартам Заказчика… именно поэтому Корпмодуль может настраиваться под разных Заказчиков — это позволит субчикам вести проекты в нескольких стандартах.
т.е. вы сами все настройки субчикам отдадите, чтоб получить всё в красивой обёртке ;)
почему? Проектировщик выставляет требования к субчику по выдаче DWG по требованиям своего СТП (которые контролирует вручную либо с помощью нашего Корпмодуля). Субчик в свою очередь также настраивает свой СТП под этого Проектировщика. Если у субчика несколько Заказчиков (Проектировщиков), то ему надо будет вести несколько СТП внутри себя (под каждого Проектировщика). Вручную либо с помощью нашего Корпмодуля… Между Субчиком и Заказчиком СТП описывается договором и требованиями.

Считаю, что автор затронул очень больную тему многих КБ. Видно, что есть понимание проблемы стандартизации выпуска КД. По моему опыту, очень часто так бывает, что КБ существует уже более 5 лет, и формально даже СТП уже есть, и все конструкторы с ними ознакомлены, но продолжают лепить чертежи так, как каждый конструктор считает нужным.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2008
Местоположение
Россия
Сайт
www.nanocad.ru
Численность
Неизвестно
Дата регистрации

Блог на Хабре