Пожелания и предложения по улучшению функционала в nanoCAD BIM Электро
Комментарии
-
Думаю, из того, что я предложил, этот пункт самый важный. Не первый раз сталкиваюсь с подобными размышлениями, в том числе среди участников телеграмм канала Nanocad Электро
0 -
Во первых «прикручивать наименование элемента, который подключен от этой коробки» идея мягко говоря не рациональная, а если от коробки подключено несколько ЭП напрашивается вопрос, по какому из них маркировка должна быть? Маркировка коробок в данный момент реализована полностью рабочая, её и так не все новички освоили, а добавлять такое не однозначное решение лишне.
Во вторых, с каких пор датчик является электроприёмником, у него есть установленная (номинальная) мощность, он преобразует электрическую энергию в другой вид энергии для её использования (п.40, ГОСТ 19431-84)? По всей логике работы датчика это выключатель и ни каком ТЗ его не должно быть (при грамотном подходе к процессу кастЫЛизации методов решения определённых задач подручными способами).
0 -
Ели 2 элемента, то и выводи через запятую или любой другой разделить эти элементы . Если Вас это не устраивает, не пользуйтесь. Все просто.
Вы размышляете слишком правильно и идеалистично. Может, когда-нибудь и появиться функционал проектирования для раздела автоматики, а пока, добавить и использовать как фишку можно.. Простым способом получается недокументируемая возможность прикручивать нанокад под свои цели (условная "палка-коробка-веревка"), отделавшись малой кровью. Прикрутить маркировку , описанную выше, с точки зрения изменений и дополнений в программе - не сложная задача для разработчика софта. Другое дело, добавить в уже существующую программу датчик как индивидуальный компонент. Это в разы трудозатратнее и никто этим заниматься сейчас не будет.
Если вы так негативно относитесь к костылянию, вот Вам пример при прямом проектировании. Например, если разрабатываете раздел ЭН, выводи КЖ по наружному освещению и маркируете коробки. В КЖ будет прослеживаться явное понимание какая коробка для каких светильников предназначена (само собой если вводите нумерацию светильников).
Прежде чем критиковать, вы хорошенько подумайте. Если Вам это не пригодится, ну и не пользуйтесь. Хуже точно не будет. А кому-то будет и лучше. И это всего лишь дополнительная возможность к уже имеющемуся функционалу.
0 -
А если не «2 элемента», в групповых осветительных сетях и 5 может быть, кому нужен этот «крокодил», если у каждого светильника маркировка по ~7 (С.<№ помещения>.<№ в помещении>) знаков будет, плюс запятая (ну или иной разделитель списка)?
Я соглашусь с вами в вашем суждении по поводу «негативно относитесь к костылянию», но этому есть причина и яркий пример, как только появилась статья какого-то «кулибина» в которой он хвалебно описывал способ как лотками чертить заземление, так с того момента в ПО ничего для заземления и не появилось, ведь и так справляются.
«Прежде чем критиковать, вы хорошенько подумайте» - тут есть вопрос, давно вы этим ПО пользуетесь? Может я действительно не достаточно глубоко постиг его гибкость?
0 -
Коллеги когда выпуск EVOS Электро на NE25? Весной можно будет подключиться к бета тестированию данного продукта?
0 -
Это не знает никто, даже программисты, которые пишут код.
0 -
К сожалению, в этом году электрики на EVOS не будет.
0 -
А ОКЛ будет? Очень нужно.
0 -
В осенней версии возможно появится.
0 -
А можно немногого, забегая вперёд, осветить предполагаемый функционал ОКЛ, как планируется, что должен выполнять, и т.д., может появятся предложения?
0 -
Ну, предполагаю, что будет плюс-минус, аналогично функционалу в ОПС
0 -
Lion прав. Будет как в ОПС.
0 -
Добрый день. Есть предложение по расчету освещенности в расчет освещенности приложить возможность вывода аналога помещения применительно к …. нормативному помещению указанному в нормативе. Экспертиза зачастую сейчас требует расписывать полностью.
0 -
Приведите образец того, что хотите получить в итоге.
А то, не совсем понятно, из сообщения.
0 -
Не плохо было бы добавить возможность вывода обоснования в таблицу «Результаты светотехнических расчётов» - пункта, таблицы и стандарта из которого был взяты свойства определяющие значения расчётных величин.
0 -
Ну это уже сделано в новом ядре (хотя я могу и ошибаться)
поэтому ту же работу в старом, "что-то меня гнетут сомнения"…
0 -
Коллеги, я правильно понял, что вы пишите об одном и том же?
Предложение принято. Согласен, что это было бы полезно. Но есть одно НО. Когда мы применяем к помещению свойства прототипа, мы не делаем жесткую привязку к прототипу, а просто заполняем данные из него. Потом можно спокойно наменять все, что угодно. И вот тут кроется возможность для ошибки…
0 -
По работе с фидерами работу улучшаем. Сделали, чтобы они копировались и перемещались в разы быстрее. Но вот групповое редактирование сделать пока не получается.
В вашем случае можно обойтись и без группового редактирования. Выделите в структуре само РУ и поменяйте у него значение свойства "Назначение в проекте". Программа предложит поменять значение для всех фидеров.
0 -
для этого надо в прототип и свойства помещения добавить поле с адресом типа откуда взяты нормы, например: «п.2, Таблица Л.2, СП 52.13330.2016». Это поле не редактируется в свойствах помещения и передаёт своё значение в отчёт при условии сохранения принятых из прототипа норм, если нормы изменены пользователем в свойствах помещения, то это не редактируемое поле обнуляет своё значение и в отчёт передаётся либо ничего, либо «-», либо примечание что это пользовательский набор норм.
0 -
Спасибо за идею. Попробуем реализовать.
0 -
На старом форуме, лет 7 назад, я аналогичную мысль высказывал.
0 -
Про замену назначения вопросов нет. Но больше требуется возможность группового выделения, чтоб можно было эту группу вверх или вниз в структуре щита переместить, либо выделить все группы и поменять количество аппаратов в группе, или марку оборудования заменить для аппаратов в линии. Корректировать каждую группу порой очень трудозатратно, когда в этом возникает необходимость.
0 -
Принято.
0 -
Хорошо
0 -
Пожелания к EVOS (на подумать)
Учитывая, что главное не сделать проект, а главное - его потом переделать.
Предлагаю, подумать над разделением РУ, т.е. как можно его разделить (ну типа как сейчас разбить комплексное РУ), что бы можно было обе части учитывать как отдельные объекты: т.е. как разделить УГО, подключения, ну и отображения в схеме.
(точно так же и к ящикам управления)
Ключевое условие: наименьшее кол-во кликов мышкой…
У кого какие есть идеи?
0 -
Поскольку EVOS обещают обновление всего и везде "онлайн", то как мне кажется, надо разделить схемную и планировочную части. Т.е. стоишь планы, присваиваешь линиям названия. Затем на отдельном чертеже строишь схемы, на них тоже указываешь имена линий и кнопкой "обновить/построить связи" создаешь связи групповых линий со схемными элементами.
Если нужно разделить щит, то создаешь новый щит, и переносишь эти линии в новый щит - и снова кнопка "обновление связей". И все, без всякий схем в окне редактора - все сразу на чертеже. Окно редактора оставить как вспомогательный функционал, когда это удобно.
0 -
"…Т.е. стоишь планы, присваиваешь линиям названия…"
Не, бро, так не пойдет.
У тебя этих линий может быть от 100 до 1000 шт. Каждой присваивать название, ну такое себе…
Моё предложение (учитывая, что электрика должна строится от схемы, а не от плана):
В редакторе схем, выделить нужные фидера и "перенести их в новое РУ", обозвать РУ, а на плане уже поставить УГО и присвоить его новому РУ, ну а сущ. трассы присоединить к новому РУ.
0 -
Меня зовут Дмтрий, не бро… 🙂
Дорогой друг! Ты преувеличиваешь проблему. Дать название 1000 линиям не такая большая проблема, чем заходить в Nanocad Электро и выбирать для каждой линии автоматический выключатель или кабель. Проблема будет в другом - нужно будет линию отчерчивать сразу целиком на всю длину, - что может быть неудобным. Но опять же - могут быть варианты!
В моем видении.
В целом можно и оставить способ формирования линий как выглядит сейчас с небольшими улучшениями, но обмен между схемами и планами должен быть. И этот обмен связями между линиями на плане и линиями на схеме должен быть постоянным. Т.е. перенес линии с одной схемы на другую, переименовал - и после этого переименовалась линия на плане. И наоборот: поменялась длина трассы, нажал кнопку обновить, и все данные переползли в схему.
Важно. Схемы должны быть "живые", т.е. отрисованы сразу и со связями, а не формироваться как сейчас по шаблонам. Редактор схем может быть вспомогательным элементом. Т.е. по сути в NE должен появиться модуль схемы, и схемы должны формироваться сразу вместе с планами на отдельном чертеже.
Также для таких "живых" схем нужно ввести инструмент "ярлыки", чтоб можно было в разные чертежи (части схемы) ставить копии любых служебных записей. Т.е. если на "живой схеме" ВРУ линия до щита отрисована, то уже в том же щите нужна копия этой линии. И если обновились справочные записи на одной линии, они обновятся и на ярлыке (примерно как на рисунке).
И так далее по этой же схеме - перенос одних линий с одной схемы в другую, далее нажатие кнопки "подключить линии к шине", далее выбор этих новых линий, далее нажатие кнопки "обновить названия коммутаторов" и "обновлении линий" "по шаблону", и все. Затем можно зайти в редактор схем и посмотреть, что можно поправить, или добавить доп. комплектацию.
В общем как-то так. Главное, если нужно что-то отредактировать, то работы на 5 минут, а не так, как сейчас.
0
Разделы
- Все разделы
- 60 Общие вопросы
- 55 Работа nanoCAD в ОС Linux
- 427 Платформа nanoCAD
- 17 nanoCAD GeoniCS
- 88 nanoCAD BIM Строительство
- 42 nanoCAD Механика PRO
- 62 nanoCAD BIM Электро
- 11 nanoCAD BIM Вентиляция
- 13 nanoCAD BIM ВК
- 3 nanoCAD BIM Отопление
- 8 nanoCAD BIM СКС
- 57 nanoCAD BIM ОПС
- 3 nanoCAD Стройплощадка
- 4 nanoCAD Металлоконструкции
- 2 nanoCAD Конструкции PS
- 7 TDMS Фарватер
- 1 Облака точек
- nanoCAD GeoSeries
- NSR Specification
- Учебным заведениям и учащимся
- 8 nano360