|
Форум посвящен вопросам релейной защиты и автоматики (РЗА). Обмену опытом и общению релейщиков. |
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Советы бывалого релейщика → Общие вопросы проектирования → Данные для прог. МПтерминалов(включая логику и уставки) в проектах РЗА
|
|
Сложно пока судить проектирую сравнительно недавно (
Но скажем конфигурирование наверно лучше делать на земле, тем-же кто делает пусконаладку. Проектировщикам это делать затруднительно и без того дел хватает
Если не будет проектного параметрирования, терминалы в целом будут работать через одно место...
Но скажем конфигурирование наверно лучше делать на земле, тем-же кто делает пусконаладку. Проектировщикам это делать затруднительно и без того дел хватает
Конфигурирование и параметрирование естественно делать наладке.
Но листы параметрирования и схему логики должные делать проектировщики.
P.S. у наладки дел не меньше, поверьте 
:)
С добрым утром!
Как сказал Женя Богатиков (это ничего, что я уменьшительным именем? Меня можно тоже, и вообще нам давно пора на ты – я так думаю)… Да, как сказал, много слов. И именно Женины посты я для себя выделил, как наиболее содеожательные. А многие о разном, и уводять от мысли.
Не буду повторятья. Попытаюсь только кратко показать, почему в проектах надо прописывать логику. Прежде всего, не надо основную логику путать с уставками,,выполняемыми на основании расчетов и логикой, которая есть придатком уставок (например, напрвленость токових защит).
Давайте покажу по аналоги с электромеханикой. Сложные у-ва РЗА имеют много реле. Расчетчики РЗА задают уставки по реле и от части эти уставки касаются и схем
( например, в той же ЭПЗ1636 или ДФЗ-201 по разному можно устанавливать отдельные перемычки в панели и отдельные провода). Но в целом схема панели не меняется от уставок.
А тепер – аналогия. Ведь с завода панель приходит закоммутированная. А если надо переделать панель по циркулярам, то это изображается в проекте, а не «Наладчики и экс-ция переделают».
Так основная логика МП терм. – это аналог такой коммутации. И эти святи надо обязательно показывать в проекте! Мне, как и Жене, ближе GE. И я его понимаю.
Это беда, Сергей (SGV), что Вы в проектах НЕ ВИДЕЛИ ПРОПИСАННОЙ ЛОГИКИ. А ЭМ панели без коммутации к Вам не приходили?
это ничего, что я уменьшительным именем? Меня можно тоже, и вообще нам давно пора на ты – я так думаю
Леонид, не вопрос.
В дополнение к твоему посту. Раньше, в электромеханике и микроэлектронике существовали ТИПОВЫЕ ПРОЕКТЫ, разработанные очень уважаемыми и авторитетными проектными институтами, такими, как Московский ЭСП, утверждённые и ввдедённые в действие Минэнерго СССР. Это не посто так, это не халам-балам. Работа любого другого института фактически сводилась к привязке типового проекта к конкретному объекту. Но всё равно, в составе рабочей документации схемы конкретных панелей были. Исключение составляют панели серии ПДЭ-2000, где проектировщики не утруждают себя перерисовывать все потроха, а просто дают привязку по внешним связям и ссылаются типовые панели.
На микропроцессорные устройства импортного производства типовых проектов, кем-то согласованных и кем-то утверждённых не существует. Каждый лепит, как может. Это конструктор ЛЕГО, как соберёшь, так и будет работать. И при любом раскладе ответственность за схемы логики должна лежать ни в коем случае не на наладке или эксплуатации, они за это не отвечают, а на проектном институте, т.к. он обязан изучить это устройство, выявить особенности и подводные камини и разработать соответствующую схему дополнительной логики. Т.к. проектный институт законодатель мод, он должен быть по своим знаниям, как минимум на шаг впереди эксплуатации и наладки. А за жёсткие связи отвечает разработчик. И если произойдёт неправильное срабатывание (отказ, ложное, излишнее) по причине ошибки в дополнительной логики, то это будет классифицироваться, как по вине проекта, ибо не надо так проектировать. На практике получается, что мы учим проектировщиков, какие необходимо предусмотреть цепи в схемах дополнительной логики.
| Присоединяйтесь!!! Мы в социальных сетях и на Ютуб. |
Женя!
Фактически ты повторил мой пост, но другими словами. Я был в шкуре наладчика МП РЗА, сей час в шкуре проектировщика. Одно время совмещал.
Самое интересное, что я одну L60 я и проектировал, и сам же налаживал. И там я в проекте прописал всю логику. Так, кстати, делает НМУ ЭЮМ Донецка (Переяславец). И не только.
А приходилось налаживать по чужим проектам, например, АВВ. И рисовать «по понятиям».
Насчет типовых проектов…ой, больная тема.
Все что я понял с этими схемами логики и параметров много проблем
Один и з вопросов который еще предстоит разобрать и понять в какой мере его сделать чтобы никому не было жалко ни денег ни потраченного времени)
Алексей!
Если Вы поняли, что написали я и Женя Богатиков, то рисовать логику – обязанность проектировщика РЗА. Рисовать или изображать другим способом, в виде таблиц. Понимаете, логика не просто должна быть изображена, а изображена таким способом, как это должно конфигурируется в данных МПтерминалах. Чтобы наладчикам непосредственно по этому проекту выполнить конфигурацию.
А то можно нарисовать уравнения булевой алгебры (или вообще еще что-то), где все правильно, но их надо переводить еще на язык данных терминалов. А должно быть без переводов: посмотрел-сделал. Вот, например, топик-стартер пишет о листах параметрирования (можно и в таком виде).
Если Вы поняли, что написали я и Женя Богатиков, то рисовать логику – обязанность проектировщика
Это я понял уже давно что в обязанностях проектантов много всего
С логикой пока не занимался, а вот параметрирование заказчик попросил сделать (хотя в ТЗ про это не было ни слова.) чем я в данный момент кстати и занимаюсь
Спорить не собираюсь с бывалыми насчет необходимости и нужности, хотябы потому что делаю первый проект.. Я абсолютно согласен что качество проектов в последнее время мягко говоря страдает, я уже слышал много раз
Но спросить вежливо спрошу)
Если не будет листа параметрирования в проекте с вводом какого из параметров МП терминала возникнут проблемы у персонала который отрабатал на данной ПС не один год, а может все 10? И который знает эти терминалы по их словам, не хуже тех кто их делает??
Спрашиваю без скрытого смысла как может показаться Не дай бог заподозрите в хамстве))
Спрашиваю исходя из ситуации которая сложилась лично у меня в данный момент..
И на что обратить внимание?
Попробуем перейти от общих фраз и философии к конкретной ситуации...
Может тогда понятнее будет почему в проектах нет таких данных.. Ну хотя бы для новичков вроде меня..
Вопрос Володе Степанову. Может, поменяем название темы. А то тут фактически не «Состав проектной документации», а, допустим, «Логики МП терминалов в проектах».
Могу и сам изменить, но лучше с топик-стартером посоветоваться.
Алексей.
Во-первых, не оправдывайтесь в том, чего Вы не делали. Далее.
1.Персонал ПС… Понятно, что Вы имеете в виду релейщиков, а не дежурных. (Дежурный не будет вникать во внутрь МП терминала. Он общается только с фейсом, и то не со всем.) Так вот, эта логика МП терминалов в проектах больше нужна наладчикам…Но об этом п.2. А релейщикам-эксплуатационникам тоже желательно знать логику. Они все же эксплуатируют эти у-ва и должны знать их внутренности.
2.Наладчик «оживляет» МПтерминал. С завода МП терминал приходит в лучшем случае сделанным «по умолчанию, в худшем – вообще какой-то болванкой. Наладчик не должен сам придумівать, какие уставки должны быть, как конфигурировать терминал. Все это должно быть в проекте. А если в проекте – только внешние связи и функции входов-выходов, то могут быть разные варианты конфигурирования (то есть, по сути, логики). И по всем правилам, наладчик не имеет права принимать решение сам, какую, образно говоря, логическую картинку рисовать из всех вохможных вариантов. Это должен делать проектант.
3.Что касается листов параметрирования…Это один из вариантов. В любом случае – логика в проекте для данного терминала должна быть однозначно прописана. А в виде листов параметрирования или иным способом – другой вопрос.
Если брать GE, то там можно в проекте логику нарисовать , как должно быть внутри терминала со всеми нужными обозначениями. Без заполнения листов параметрирования.
4.И тут, кажется я понимаю, порой заставляют проектантов, которые и так логику изобразили, еще и листы параметрирования заполнять. А вот это вопрос, надо ли.
Но, может потому и заставляют делать листы параметрирования, что логики в проекте нет. Может, будь она, наладчики сами бы все меню заполнили.
5.Я подозреваю еще, что заполнения листов параметрирования требуют в задании на проектирование…Правильно ли? Вопрос…
6.Однозначно: логику для МП терминала в проекте изображать надо. Но не уверен, что заполнение листов параметрирования вдобавок – это не каприз.
Володя. Я с Вашего разрешения меняю название.
По-моему, этот вопрос обсуждался неоднократно. И листы параметрирования выдавать проектировщику необходимо. Именно в этих листах задается информация, необходимая для корректной работы устройства. В логике прописано, условно говоря 5% информации,необходимой для работы устройства. Остальные 95% - в листах параметрирования. Кто-то ведь должен нести ответственность за правильную работу предлагаемой схемы. И это однозначно должен быть проектировщик. Сейчас эту работу (листы параметрирования) пытаются "спихнуть" на эксплуатацию, на системного оператора,на производителей, на наладчиков, но только из-за безграмотности определенной части проектировщиков. Возьмите, к примеру проекты солидных фирм: московского ЭСПа, ОРЗАУМа, и еще кое-кого - там есть все вышеуказанное....
Валера (Конспиратор).
Вы (или мы уже на ты – забыл). Я повторю вопрос топикстартера: есть ли документ, обязывающий проектировщика делать эти самые листы параметрирования. Тут же вопрос еще и в стоимости проектирования. Входит ли составление этих листов в стоимость проектирования или это отдельная работа, которая должна отдельно осмечиваться?
И еще. Можно переслать какой-нибудь из фрагментов проекта одной из этих солидных проектных организаций, где есть листы параметрирования? И, вообще (повторюсь) , нормируется, как их заполнять? Или это просто пункты меню, составленные в произвольной форме. «Произвольной» я имею в виду в части оформления в проекте. Понятно, что они должны соответствовать таблицам в программах для данного МП терминала.
ОФФ:
имхо, конфликт: как должно быть или как правильно, и как хорошо. Грамотные проектировщики везде теперь не скоро появятся. Их надо учить. Мы часто делали так: приезжаешь на объект, сажаешь рядом с собой релейщиков, и говоришь: ну теперь рассказывайте, что Вам надо. Если можешь, делаешь, не можешь - совместно находятся другие решения, параллельно - доучиваешь. Когда все настроено и проверено/испытано, отсылаешь это проектировщикам. Те либо учатся, либо - нет. Вторые попадают в белый лист, с ними и дальше работаем, и другим говорим - эти хорошие. Не учатся - в черный - и в ФСК - эти плохие... Со временем появились доверенные проектировщики, те за которых лучше сделать самим, и те, с которыми релейщикам придется разбираться тет-а-тет (и если вы с ними продолжаете работать - ваше право кормить бездельников и неучей)
Леонид, я уже писал, документа, обязывающего проектировщика делать параметрирование терминала, пока не существует. Есть только письмо СО, которое по большому счёту для проектировщиков просто клочок бумаги и есть ТЗ на разработку проектной и рабочей документации, которое для проектировщика закон. Вот в этом ТЗ мы и прописываем все требования к составу документации.
А какой объём пропускает почта? Могу выслать пример проектного параметрирования.
Евгений, пожалуйста вышли мне.
Интересно и очень, я сейчас для себя создаю базу, практически с нуля, опыт других всегда интересен.
Согласен с Sergei в любом случае должен быть диалог сторон проектировщик-наладка-эксплуатация. И по поводу списка "плохих" для тех кто не желает учится. Однако по поводу полного листа параметрирования (если его выдавать)
все таки стоит, я думаю, отметить то что в нем проектировщик обязан прописать логику работы схемы так как без него сложно будет наладке и эксплуатации догадываться до сути, да и не входит это в их обязанности.
Однако полностью все уставки прописать будеть затруднительно, как то значения срабатывания ступеней МТЗ, ДЗ, дальний резерв, выдержки времени в общем подобного плана.
Это должна считать эксплуатация (например РДУ) просто потому что они обычно имеют наиболее полную картину исходных данных по сети, свои какие то хотелки в этом плане и допущения, им потом с этим жить.
А проектному институту таких данных не дают или это вылезает в нуднейшуу переписку и соответственно срыв всяких сроков.
И к наладчику этот лист должен в полном объеме собраться от обоих сторон проектировщик-эксплуатация, они уж точно не должны чего считать, их задача "оживить".
P.S.: возможно я когото повторил или чем то не прав, но пока из личного опыта получается как то так.
35 Мб, однако. Потянет почта?
маил.ру вроде тянет без проблем
Советы бывалого релейщика → Общие вопросы проектирования → Данные для прог. МПтерминалов(включая логику и уставки) в проектах РЗА
