polomnik

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

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

Про галку, беру претензии назад. Действительно с 21 версии заработало, недопроверил галку в верхних версия. Спасибо!

Можно ли как то починить таблицу ЗКПС, которая отказывается выводить разные извещатели в одной ЗКПС? Ладно с ИПР, для которых можно назначить свой номер ЗКПС, но для ИП с изолятором КЗ и без изолятора КЗ -уже присваивать свои ЗКПС -не вариант, а в таблице ЗКПС выводится только один тип ИП, а другие откидываются без указания номера ЗКПС.

Толковая идея и реализовано не плохо, особенно в части выборки только фактической длины кабеля, проходящего через конкретный участок КНС ОКЛ. Спасибо! Но так и не смог добиться от программы вывода крепежных элементов и элементов несущей для лотков, входящих в состав конфигурации узла крепления. К разделу ОКЛ спеки не цепляется ничего из состава конфигурации узла крепления лотков, цепляются только объёмы из конфигурации соединительных элементов. И даже это не увидеть в разделе ОКЛ спеки без дополнительной команды на подбор соединительных элементов, что теперь нужно не забывать делать после каждого добавления новой кабельной связи через целевые КНС и обновления модели. Не цепляется в раздел ОКЛ спеки и состав крепежа и крепления, встроенных в КНС через УГО КНС. В настройке спеки вижу таблицу «материалы» и ещё кучу таблиц можно подключить, но как указать требуемым материала, что они входят в состав ОКЛ –не понятно, а назначать материалам данный признак –важно, например не всегда используются коробки как элемент подключения, а чаще как добавка в файл комплектации, а также есть тьма компонентов ОКЛ, которые не редко требуется добавлять вручную, те же коробки с их элементами крепления, трос с его подвесом по всей длине, участки дополнительного крепления и т.п. Необходимо развязать руки пользователям для добавления любых материалов в раздел ОКЛ спеки под требуемое исполнение ОКЛ. Ещё один момент сильно напрягает, хотя не по теме ОКЛ. В таблицу прокладки кабелей попадает не фактическая длина КНС, а длина равнозначная длине кабеля, и если для лотковой трассы или короба, это можно объяснить интересующимся персонажам, то для трубы, где проложено не более одного кабеля, аргументы заканчиваются, когда итоговой длины трубы для затяжки кабеля (не более одного в трубу) в таблице прокладки кабелей, выходит на сотни метров больше, чем заложено по спецификации.

Вот и я перелопатил тучу объёма, что бы разделить его на этапы и с ужасом обнаружил, что кабелям в электрике по барабану выборка через маркеры. Вот это поворот. Какой тогда смысл маркеров для электрики ума не приложу (не встречал электрику без проводов). В ОПС с кабелями нет проблем. Неужели не в силах программистов сделать выборку кабеля привязав его к автомату, от которого он подключен, как уже сделано в ОПС, где даже в пределах одного прибора можно назначить разные маркеры на разные шлейфы и всё работает. Или всё упирается в ту же беду, которая до сих пор не позволяет отключить кабель для вывода в спецификацию, сколько не щёлкай назначенный для этого флажок? Это какой то позор..., как сказал бы Жванецкий(Швондер).

Доброго времени суток, Предлагаю, подумать о модели питания двухфазных нагрузок. Лично на моей практике очень часто, от слова постоянно, встречаются прожекторы с двухфазным питанием (без рабочего нуля), и пока приходится делать вид, что оно однофазное, ставя двухполюсные автоматы. С тем получаются завышенные значения в расчетах по падению напряжения со всеми вытекающими по ненужному увеличению сечения кабеля. Если модель с двухфазными нагрузками слишком сложна в реализации, то нельзя ли включить возможность расчёта по введенным вручную параметрам? То есть, например, я точно знаю ток потребления по паспорту оборудования и программа позволяет ввести значение вручную, но эти изменения никак не влияют на расчёт падения напряжения, хотя отражаются в таблице групповых щитков, выводятся в однолинейную схему и с тем создают конфликт результатов, где падение напряжения не соответствует указанному току. Если с этим нет возражений, то было бы не лишним добавить в список «Имя фазы» (в характеристиках аппаратов защиты в структуре шкафов) значения типа АВ, СА, ВС (к которым, по моему субъективному мнению, можно не придумывать специальные алгоритмы действия, достаточно их выводить в однолинейную схему, в таблицу результатов расчетов и в таблицу групповых щитков, т.е. куда значение фазности попадает сейчас).

Я в таких случаях давно пользую созданные пустые КНС (без креплений и т.п.), с отличительным названием каталога по которому не подбираются углы, повороты... и т.д., Например для лотка: Сочиняю название самого лотка под спеку "Существующий лоток 50х200х3000 (учтённый в смежных проектах или иных объёмах. Учёт укладки кабеля). Производителя и марку не проставляю, и ничего из спеки не убираю ибо править, что то ручками плохая практика т.к. сегодня помню, а через неделю, две, три... что то добавил или убрал в объёмах, заново выгрузил и уже не вспомнил, что нужно что то подчистить.

Не знаю, что как поправили, но задолбала эта проблема в электро, СКС и ОПС из под 20-ки. Ощущение, что насколько программа убыстряет работу, ровно на столько она поджигает зад с косяками по разным мелочам.

По моему, тут нет сложности, или я чего то упускаю. Понятно, что функционал «ящик с трансформатором» построен под конкретно ЯТП и к нему в этой части -нет вопросов, но в настоящий момент, этот «ящик с трансф.» -единственный инструмент, через который можно построить слаботочную сеть освещения, назначая его как драйвер. Уже научили выводить в журнал кабель за трансом, падение считается (осталось отделить его от общего падения), ну и просто разблокировать косинус, что бы «шкаф с трансом» мог брать его из ГХ, и тут, кто применяет это для ЯТП поставит 1 или не будет включать ручное указание и получит 1 по умолчанию, а кто пользует этот шкаф как драйвер –укажет нужное ему значение. Даже не знаю, -есть ли смысл (в будущем) создавать отдельный элемент типа «драйвер LED», хотя было бы зачётно. Ещё бы прикрутить пусковой ток с расчётом и/или проверку на максимальное количество для разных типов автоматов, которые пользователь сам заполнит по данным производителей, а ПО не даст в итоге ошибиться. Ещё, не плохо было бы выставлять допустимое падение за трансформатором (конкретно в модели трансформатора в проекте, а не в свойствах проекта, ибо у разных слаботочных потребителей различные допуски по падению) и тоже заложить в проверку. В расчётах хотелось бы видеть итоговое напряжение на входе каждого потребителя (на данный момент видно падение). …Не удержался с хочухами.

Других вариантов и нет. Обнаружил для себя более удобный и быстрый бубен, пока не родится штатного инструмента (может кому пригодится). Оказалось, проще указать для слаботочных светильников минимальную мощность, а при необходимости перепроверки падения –подставить требуемую. В остальное время жить с минимальной мощностью на слаботочных светильниках (сумма падений уже не режет глаз), с тем очень удачно, что потребление считается от мощности трансформатора а не от нагрузки за ним. Кстати о ящике с трансформатором. Он так и должен игнорить указанный косинус (из ГХ)? Он всегда выводит 1.

У меня посыпались объекты с BIM, и регулярно двигают локальные шкафы с централизованными дровами под светильники, -приходится постоянно проверять падение на слаботочке и оказалось удобным всегда держать клон для каждого драйвера. Заново подключить группу драйверов, за которыми стоят светильники (что бы началось считаться падение на слаботочке), а потом вернуть подключение только клонов дров, - требует меньше усилий, чем подключать и сами светильники за дровами и заново обновлять трассу от каждого драйвера. Сейчас починили кабели за трансами и заменять штатное подключение на контрольное больше нет смысла, а собрать цепочку из кучи светильников на контрольном подключении ещё та работка, хотя раньше только так можно было засунуть эти кабели в журнал. Вот оживят новый параметр падения без суммирования и весь этот геморрой уйдёт в прошлое. Кстати, может есть смысл создать и отдельный параметр падения на слаботочке. Я бы прикрутил и его.

Океюшки. Очень нужно. А то приходится разрушать подключение и переподключать на стадо клонов БП, что бы изъять падение на слаботочке. У меня сейчас в работе объект где под 1000 драйверов.

Доброго времени суток! Подскажите, кто знает. В программе ещё не появился параметр для выгрузки падения напряжения без его суммирования с падением на слаботочной линии за трансформатором? (имеется ввиду шкаф с трансформатором)

Да, хочу, что бы было так, только цифирь перед маркой кабеля не вылезает. Выноска по трассе количество отображает, а в однолинейке нет. Какой параметр за это отвечает для выноски в однолинейке? ОК, Всем спасибо! Создал проект с нуля в 20, и всё отрабатывает как и хотел. Буду посмореть, почему в текущем проекте такой косяк. Разобрался. Количество кабелей в однолинейке отображается только для типов отходящей линии "Питающий" и "Распределительный".

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

Очень годная инициатива. 1. –Согласен, с Lion2032 и doctorraz, для 1 и 2 категории нужно примерять всю мощность на каждом вводе 2. –Тоже склоняюсь к расчёту без учёта перекоса. Расчёт с учётом перекоса полезная вещь, но в частных случаях, и было бы не плохо видеть в составе отчета в таблице «Расчётных величин» -результат и с учётом перекоса. И оставить пользователю выбор на выгрузку результата с учётом перекоса или без учёта. 3. –Такую проверку делать точно нужно. Случаев, что бы одна нагрузка была больше расчётной не попадалось, но, что иногда выходит очень близко к расчётной, практически ничего не оставляя другим потребителям, -так бывает. Бывает, что есть два мощных потребителя (например: промышленные плиты), а расчётная выходит чуть меньше их суммы и это фиаско, ведь в моменте оба потребителя могут работать одновременно и на всю мощность, а остальные ЭП вообще обделены вниманием. Приходится тупо ставить Кс=1 4. Однозначно, такой функционал нужен. Есть объекты с мощными потребителями аварийной вентиляции по датчикам СО и т.п. И в рабочем режиме им собственно делать нечего, но иногда их включение сблокировано с отключением какой-либо технологии, а иногда это просто дополнительная нагрузка к рабочему режиму и аварийный режим уже становится больше рабочего.

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

Такая бяка всегда вылезает если устанавливать УГО и прокладывать трассы привязываясь к примитивам "кривой архитектуры" Очень часто приходит подобное творение планировок с разбросом слоёв по оси Z, а иногда даже не видно какой слой тупит. Я для верности всегда выключаю привязку при расстановке УГО, а трассы уже привязываются к УГО. Для скорости работы очень удобно использовать многокнопочную мышь с привязкой частых команд на доп.клавиши.

Согласен, тоже вариант.

Ещё не остыл принтер, а разработчики и СП484, и СП6 -уже сливаются готовностью вносить поправки в свои творения, после первых же встреч с теми, кому это пользовать. И как всегда, не ради здравого смысла, а, чтобы прикрыть свои косяки после оплаченной, длительной и упорной работы. Это просто талант –изложить очередной нормативный документ, где ключевые моменты содержатся в устных комментариях. И такие творения принимают законную силу? Если до встречи с господи_ном Варламкиным ещё теплилась надежда на здравый смысл, то после изложения того, что на самом деле предполагали разработчики, -становится дурно. -Какой смысл в п.6.3, сияющий, сперва, адекватностью, а на деле п.6.3 не живёт без п.6.5? Зато какие посылы здравого смысла на предмет достаточности кабелей не FR для светильников и приборов с встроенными АИП, а также нормально открытых клапанов. Как сладко звучали рассуждения И.Рыбакова о бессмысленности кабелей FR для пожарной сигнализации и всё это мы увидим в СП6. Увидели. Только А.Варламкин изменился в лице, когда осознал, что для кольцевых линий связи забыли указать, что это только для извещателей. Ребята уже, в тихую, потрудились над ГОСТ 31565, ради сглаживания конфликта по допустимости кабелей не FR для СППЗ. Кстати, никого не смущает бесцеремонность, с которой творцы СП484 внедрили новую аббревиатуру СППЗ? На кой это было делать, если нормативка кишит давно устоявшимся видом «СПЗ», включая более старшие документы и даже СП6 не пошел на поводу СП484. Но это лишь неудобство, а грусть в том, что значимость ГОСТ Р 53316 ничуть не ослабла и радостно распространилась на п.6.3. С нетерпением буду подождать первых результатов испытаний, когда кто-то из нынешних производителей ОКЛ на это сподобится. В этом уже кроится бессмысленность п.6.3, если не сподобится никто или не скоро. И будет очень смешно если кабели не FR не смогут продержаться даже 5-ти минут по ГОСТ Р 53316, когда как под тему кабелей не FR уже причесывают ГОСТ 31565. Нормотворцы осознают, что могут попасть в неудобную позу? Хотя не в первый раз и без каких либо последствий для них. Далее, какой вообще смысл в абзаце про огнестойкие короба в п.6.3, если, все эти фантики накрыло пунктом 6.5? Что получит сертификат, то и будет можно пользовать. На выходе, при любом раскладе, не вижу для себя преференций по использованию кабелей не FR, даже если кто-то сподобится получить сертификат. Ибо, время работы будет однозначно минимальным, его нужно притягивать к обоснованию необходимого времени работы СПС, по расчёту которого нет никаких методик, при этом, в какую норму должен вписаться полученный результат испытаний на кабелях не FR, для светильников и приборов с АИП, а также НО клапанов, создатели п.6.3 СП6, наверно, вообще не задумывались. Всё, пока, настолько бестолково, что вешать на себя ответственность за проектные решения во имя экономии бабла заказчика, -лично я -не готов.

Что то у меня не удалось повторить Ваш успех с разрывом трассы. Похоже он тут не главное, а направление зависит только от менее длинной трассы от последнего датчика до прибора по требуемому направлению прокладки трассы. Так иногда получается подгадать но в условиях реального проекта, при прохождении по общей трассе других кабелей, имеющих свои потребности по топологии трассы, да ещё в условиях внесения изменений в топологию трассы, -можно легко проморгать, что петля пошла не по плану. Это уйдёт в работу, кабель посчитается по кротчайшему расстоянию, и монтажники так и проложат.

Рядом, но не в одной трубе/лотке/жгуте и т.п., да ещё на дистанции 300мм. Как теперь будет выглядеть спуск к ИПР в двух трубах, разнесённых на 300мм? Маразм ВНИИПО крепчает. (Для ИПР, пока, штатно один трубный ввод). Причём этой пурги не требуется для не адресной линии. Остаётся ставить не адресные ИПР через адресную метку. добавлено через 7 минут С этим функционалом далеко не уехать. Вы же видите, что считается лоток/короб/труба -отдельно для каждого кабеля. Будет батарея коробов, труб, лотков, хотя всё вмещается в один лоток/короб/трубу, а требуется сделать возврат одного кабеля в отдельной трубе, или совместно с другими кабелями, но тоже в отдельной (от другого кабеля кольцевой линии) трубе. При этом, указание по прокладке не более одного кабеля в трассе, не поможет проложить кабель по требуемому направлению, т.к. просто удвоится количество трубы, и кабель вернётся по кротчайшему расстоянию. Это годится только для отвода кольцевой линии на датчики в помещение и т.п. (для учёта второй трубы).

Вопрос не по теме теста, но по теме "подарков" от СП484. 1.Как-то планируется решить с прокладкой кабелей по требуемым трассам, а не всё в кучу по кратчайшему расстоянию? Ибо теперь обе полу-петли адресной линии не могут идти в одной трубе/лотке/коробе, да и для интерфейсных линий уже в планах подобные требования, и уже есть заказчики указывающие раздельную прокладку интерфейсов. Уже приходится изгаляться по-всякому. Пока пользую бризы как опорную точку направляя через них кабели шлейфов по трассам, а для интерфейсов -коробки. Но если на схемах и в спецификации это можно скрыть, то в журналах это дело не спрятать и в структурке оно вылезает. Может сделать как в электрике, где для каждой группы можно вручную назначить трассу. Или для шлейфа назначать маркер трассы, а для маркера указывать трассу вручную, и при добавлении шлейфа и обновлении модели -шлейфы будут прокладываться по трассам своих маркеров, а шлейфы без маркеров –по кротчайшему расстоянию (как сейчас). 2.Пожелание. Лично у меня уже назрела необходимость прибора с встроенным блоком питания, чтобы штатно добавлять аккумуляторы в такой прибор и считалось потребление (как уже реализовано в БП). Пока приходится это ваять как шкаф с прибором и блоком питания внутри, но со времени как в структрурке начали отображаться БП, то не редко такую компоновку разбрасывает на разные листы, да и простое соседство прибора на одной строке этажа, а его встроенного блока питания на другой строке этажа –выглядит не очень, да и кабелю между прибором и его блоком питания нечего делать в журнале.

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