Перейти к содержимому


nanoCAD ОПС. Проблемы и предложения


Сообщений в теме: 3

#1 bvg

    Активист

  • Пользователи
  • PipPipPipPip
  • 197 сообщений
  • Пол:Мужчина
  • Город:Екатеринбург

Отправлено 29 Сентябрь 2016 - 12:40

Здравствуйте, коллеги
Всем мы являемся пользователями пакета nanoCAD ОПС различного стажа работы с ним и различного опыта, специалисты проектного отдела нашей организации начали знакомство с nanoCAD ОПС с 06.2011г.
За это время было выявлено значительное кол-во проблем, информация о которых приводилась на нашем форуме от bvg.
Хотелось бы отметить оперативность ведущего Бадаева Максима на описываемые проблемы, правда справедливости ради - не всегда дело доходило до решения.

Думается, что было бы весьма полезным сформировать некий ОБЩИЙ перечень проблем, которые не были решены по состоянию на настоящее время, так как анализировать ВСЕ ТЕМЫ форума довольно утомительно, и наверное не реально.
Попытка сформировать общий список нерешенных проблем была предпринята Максимом Б. в теме nanoCAD ОПС 6.0, прежние проблемы, но, к сожалению, список ограничился только информацией от меня, без обратной связи.

Мною неоднократно высказывалась просьба о предоставлении информации о принятии того или иного предложения и сроках реализации проблем, но …. !!!

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

В очередной раз обращаюсь с просьбой к разработчикам nanoCAD ОПС, все-же предоставить информацию о принятии той или иной проблемы к решению и сроках реализации решения проблем!!!

Было бы неплохо, если бы эта СВОДНАЯ информация (в том числе и пометками о решении) постоянно обновлялась и была бы доступна для всех пользователей (в том чиле и потенциальных) на сайте http://www.nanocad.ru/, может быть по аналогии с информацией Что нового в разделе nanoCAD ОПС.

СПИСОК НЕРЕШЕННЫХ ПРОБЛЕМ:
  • Применение ответвительных коробок (для линий электропитания, оповещения и пр., ветвление типа "звезда"). Возможность применения КНС – тросовая / струнная прокладка каб. линий. Проблемы обсуждались с 09.2011г., а также 13.10.2015г..
  • Обеспечение возможности добавления всех элементов БД групп с аппаратурой в 19" шкафы, добавляются только звук. усилители и кабельные организаторы. Проблема обсуждалась 09.2014г,, 11.2015г..
  • Задание / редактирование Кзап (МАХ-ая емкость КНС) для разных участков каб. линий, например для гильз и трубных трасс. Проблема обсуждалась 08.2013г., 11.2014г..
  • Не решена проблема по корректному подбору каналов для каб. линии для случаев:
    • автоматический подбор каналов при "Ограничении кабелей для канала - По количеству"
    • автоматический подбор каналов отключен
    Проблема обсуждалась 11.2013г., 11.2014г..
  • Исключение символа "." в имени кабеля при отсутствии СУ в Таблице прокладки кабелей и применение шаблонов имени кабелей. Проблема обсуждалась 11.2014г., было обещание решить этот вопрос в v6.1.
  • Организация выноски для участков каб.трасс с отражением номеров кабелей по Кабельному журналу. Проблема обсуждалась 11.2013г..
  • Некорректное отображение порядка подключения ПИ в адресном шлейфе в форме: Электротехническая модель, режим "Шлейфы" левая и правая части, см. скрин-шот "ЭлтехнМодель НесоотвПорядкаПИ_.JPG". Ранее обращалось внимание на несоответствие порядка подключения ПИ в адресном шлейфе в формах: Электротехническая модель, режим "Шлейфы" левая часть и Мастер подключения оборудования – исправлено.
  • В таблице прокладки кабелей не совпадают длины кабелей с суммой длин КНС. Проблема обсуждалась 10.2014г.
  • Задание параметра "Локализация" (форма Настройка, группа Система). Проблема обсуждалась 09.2014г., 11.2014г..
Значительная часть выше приведенных проблем обсуждалась не только по приведенным датам, остальные ссылки не приводятся.

Прикрепленные файлы



#2 flagman

    Активист

  • Пользователи
  • PipPipPipPip
  • 179 сообщений
  • Пол:Мужчина
  • Город:Сочи/Тюмень
  • Интересы:Электроника, проектирование систем связи, безопасности. ~/FreeBSD

Отправлено 05 Октябрь 2016 - 15:21

Добрый день!
Хотелось бы внести свое видение решения задачи:
1) Применение ответвительных коробок (для линий электропитания, оповещения и пр., ветвление типа "звезда").
На мой взгляд, в меню каждого соединения приборов сейчас присутствует возможность выбора топологии между шиной и кольцом, необходимо добавить новый тип "звезда",
чтобы к этому шлейфу каждое устройство подлючалось индивидуальным кабелем. А тот мудреж с ответвительными коробками который указан в документации это утопия,- имхо.
гораздо удобнее будет если добавите новый тип "звезда", а коробки будут настраиваться как УЗКЗ типа БРИЗ.


#3 Станислав Коваленко

    Новичок

  • Пользователи
  • Pip
  • 4 сообщений

Отправлено 07 Октябрь 2016 - 12:01

Добрый день.
Благодарю bvg за представленную подборку нерешенных проблем, также хочу внести свою лепту в улучшение данного продукта.

Здесь и далее я говорю только о версии 8.0.

1) В БД отсутствует такой тип оборудования, как коммутатор. Реализовывал IP-видеонаблюдение путем создания видеоразветвителя и нового подключения для этого разветвителя и камер. Получился прибор с n шлейфов типа "информационная линия" с топологией шина и 1 адресом в шлейфе. То же было проделано для камер, питание установлено по шлейфу. Костыль не сложный, но не вижу проблем добавить тип подключения "ethernet" и учитывать там питание по PoE.
2) Нет возможности совместного использования КНС для разных систем. Решения предлагаемые на форуме не считаю удобными. Честно признаюсь, что не имею представления о возможности реализации своего видения по данному вопросу с технической точки зрения, но мне бы хотелось видеть следующее:
В моем отделе трудится 4 человека. Все специалисты могут выполнять любой раздел СС. Но, в случае сжатых сроков по проекту, я разделяю между ними один объект по системам. Один делает ОС+СКУД, второй ПС+СОУЭ, третий СКС, четвертый СОТ. Специалист который делал ПС+СОУЭ (например) самый шустрый и быстро накидал КНС, учтя при этом, что коллеги захотят воспользоваться его лотками. Для этого у КНС должна быть привязка в конкретному проекту. Специалист выполнявший СОТ, закончив подбор оборудования и расстановку его на плане, знает, что КНС уже отрисованы и можно проложить свои кабели в них. Он открывает некое меню "импорт КНС из смежного проекта" и в проводнике выбирает файл проекта из которого хочет импортировать уже готовые конструкции. То же делают и остальные. На плане проекта, в который были импортированы КНС, они (эти КНС) выделены каким-либо образом/при наведении на них мышкой всплывающая подсказка говорит о том, что КНС принадлежит такому-то проекту/можно поставить специальную выноску с информацией по КНС или все и сразу.
Открытым остается вопрос как посчитать общее заполнение КНС. Для этого исходный проект должен "знать" кто использовал его КНС и сколько кабелей в них положил. Для этого, при импорте данных из одного проекта в другой, исходный проект должен быть закрыт, а в меню импорта должен быть пункт "экспортировать (сообщить) результат импорта владельцу исходного проекта по завершении работ". В данном случае получается пусть не параллельная, но совместная последовательная работа с проектом нескольких специалистов. Что бы не останавливать работу владельца исходного проекта при обращении к его КНС смежных специалистов, можно вносить информацию по КНС в отдельный файл, а не в файл проекта. Для того, что бы корректно отслеживать заполнение КНС, в меню должна быть кнопка "обновить заполнение КНС", при нажатии на которую любой участник проектирования смог бы увидеть количество кабелей с указанием их принадлежности к тому или иному проекту, а также сообщение о превышении используемой емкости КНС.
Данный метод работы подойдет и для одного специалиста выполняющего разные системы в разных томах. Если что-то упустил, укажите, готов подискутировать на тему предложенного мною способа совместной работы над проектами.
3) Считаю что продукты Нанокад СКС и ОПС должны быть объединены. Потому как в подавляющем большинстве организаций выполняются одними и теми же специалистами. Также, помимо просто логичности их объединения, пользователь получит возможность использования совмещенной базы данных, что позволит подключать те же камеры к коммутаторам ЛВС, использовать инфраструктуру СКС для сетевых СКУД и т.д. и т.п. Это очень важно для меня лично и для проектировщиков слаботочки в целом (ИМХО, конечно, кому то и на кульмане хорошо дается интеграция систем). Вопрос удорожания конечного продукта не рассматриваю, т.к. это технический раздел форума.
4) При работе с менеджером баз данных, при выделении прибора есть возможность выбрать 3Д представление для него, но данное представление можно только импортировать, хотелось бы видеть вкладку "создать". Также должен отметить, что импортировать из DWG у меня не получилось, открывается проводник, выбираю нужный файл и ничего не происходит. При нажатии "ок" окно импорта просто закрывается, но точный вид не обновляется. Возможно это ограничение пробной версии.
5) Просто необходимо добавить на структурной схеме возможность установки специальных выносок с типом и длинной кабелей. Установить вручную не сложно, но реализация данной функции сделает работу со структурной схемой действительно приятной. Также хотелось бы видеть на структурной схеме и линии питания, как 220В, так и 12/24В.
6) Хотелось бы видеть возможность выбора для лотков и коробов представления в "натуральную" ширину на 2Д планах. До использования Нанокада применяли динамические блоки от ДКС. Получалось очень наглядно и удобно, как для проектировщика, так и для монтажника. Да, можно просто налепить эти же блоки поверх трассы в пространстве модели, но это опять костыли, да и просто лишние элементы в чертеже, причем "тяжелые" элементы.
7) Было бы приятно, если бы в 3Д представлении для лотков отрисовывались в т.ч. и конструкции крепления в соответствии с выбранной конфигурацией. Что бы было, например, понятно не протыкаю ли я своими спицами идущий выше лоток электриков. Да и просто это даст более детальное представление о расположении системы в 3Д модели здания. Это конечно просто хотелка.

UPD

8) Хотелось бы увидеть инструмент по подсчету проходок через перегородки и перекрытия. Реализовать можно через УГО с выводом в таблицу Exel/Word/CAD. Данные УГО должны устанавливаться на трассу и иметь такие свойства как: материал перегородки/перекрытия, толщина перегородки/перекрытия и размер отверстия. И если возможно, было бы супер, будь у данной функции привязка к БД, например огнестойкие проходки от ДКС и/или автоматический подсчет труб (гильз).
*Где-то на форуме этот вопрос уже поднимался, добавляю к своему посту, т.к. разделяю актуальность данной задачи.


По мере появления новых замечаний/пожеланий буду добавлять их в этот пост.

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

Сообщение отредактировал Станислав Коваленко: 13 Октябрь 2016 - 12:47


#4 polomnik

    Посетитель

  • Пользователи
  • PipPip
  • 37 сообщений

Отправлено 03 Январь 2017 - 03:10

Разрешите внести предложение в части оформления таблицы «Результаты расчёта токов» где строка «Требуемая ёмкость РИП с учетом коэф. использования -- (W), А*ч» не отражает своё содержание, и более логично (по результату расчёта на основе установленной ёмкости АКБ на коэф. использования) назвать её как «Доступная ёмкость РИП с учётом коэф. использования -- (W), А*ч. Конечно, её содержание всегда можно заменить и перед выгрузкой и после выгрузки (что и делаю с версии ОПС4.2), но иногда, после обновления расчётов, про это забываешь, и в итоге очень глупо выглядит утверждение «Требуемая» когда допустим, -значение явно превышает расчётное (по суммарной ёмкости деж. плюс трев. в несколько раз (по объективным причинам. Запас на расширение и т. п.) или значение меньше расчётного (если объект с питанием по первой категории и важны расчёты только по току). При этом понятие «Требуемая ёмкость РИП» звучит конструктивно и солидно и исключать его из таблицы не стоит, но очевидно, что данное значение следует рассчитывать на основе суммарной ёмкости деж. плюс трев. на коэф. использования (только коэф.исп. в большую сторону).







Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 скрытых пользователей