не свалится. Надо только вставить в программу (и загрузить в контроллер) OB80.
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
Одинаковая наработка оборудования — это фантастика, сферический конь в вакууме.
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Фирменные контроллеры относительно дороги, да. Однако, рабочее время (и спокойный сон) довольно большого количества специалистов тоже чего-то стоит ;)
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Там не скважины, а водопровод на входе. Просто давления не хватает.
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
По-хорошему, так сильно паковать и не стоило: плюшкинизм какой-то :)
Отдельный регистр под статусы, отдельный — под уставку таймера, отдельный — под текущее значение таймера.
Или бились за уменьшение объёма данных с целью сэкономить на лицензии для SCADA? ;)
За что люблю Siemens — ему не надо каждый раз объяснять алгоритм «как почесать левую пятку», он это на уровне операционки делает. Но вот Modbus и Siemens в моей практике до недавнего был тяжело совместимым. Но с относительно новым их модулем для ET-200S (он ещё и недорогой, кстати) стало полегче :) До этого всегда старались использовать шлюзы AnyBus.
PS а кроме геморроя со связью есть ещё фильтрация аналоговых значений + диагностика каналов, фильтрация дребезга дискретных входов… В общем, даже на мелочёвку иногда руки чешутся PCS намазать :)
Этот сервер принадлежит конторе, которая обслуживает много таких проектов. У них резервированный канал в инет, хороший сервер, специальные люди занимаются его поддержкой. И зачем это делать самим? Данные не настолько секретные. Я бы сказал, что для третьей стороны они вообще ценности не представляют. А ставить другие железки/VPN… Так опять, если свалится — кто поедет поднимать? Да и контроллеры стоят разные, Ethernet есть, пожалуй, только в сименсовских. И 232 порт не во всех есть — большей частью 485. Общего — только Modbus. Т.е. придётся практически, полноценный компьютер ставить, поднимать на нём Modbus/интернет шлюз, и упихивать его в обычный электрошкаф по соседству не только с контроллером, но и с пускателями, частотными приводами и софт-стартерами. На эту железку, опять же, надо что-то намазать. А ещё там напряжение может внезапно пропасть и внезапно возникнуть. И что со всем этим делать?
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
Защита, как раз, простейшая. Была ещё мысль сделать таймер, который отсчитывает, сколько времени прошло с падения связи при работающем насосе и по тайм-ауту (если связь не вернулась) отключать. Но остановились на первом варианте. На самом деле, даже такой вариант работает вполне приемлемо.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.
Тут цепочка подрядчиков. Собственно, заказчик — контора (около)государственная. Мы работаем на субподряде. Кроме автоматики, другие субчики ремонтируют сами станции, заменяют/добавляют оборудование.
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
Как хорошо было бы, если б депутаты не были идиотами и не совались со своими инициативами в интернет и к блоггерам…
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
Отдельный регистр под статусы, отдельный — под уставку таймера, отдельный — под текущее значение таймера.
Или бились за уменьшение объёма данных с целью сэкономить на лицензии для SCADA? ;)
За что люблю Siemens — ему не надо каждый раз объяснять алгоритм «как почесать левую пятку», он это на уровне операционки делает. Но вот Modbus и Siemens в моей практике до недавнего был тяжело совместимым. Но с относительно новым их модулем для ET-200S (он ещё и недорогой, кстати) стало полегче :) До этого всегда старались использовать шлюзы AnyBus.
PS а кроме геморроя со связью есть ещё фильтрация аналоговых значений + диагностика каналов, фильтрация дребезга дискретных входов… В общем, даже на мелочёвку иногда руки чешутся PCS намазать :)
Дешёвый он. Вот, пожалуй, главный плюс.
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.