Программа управления объектом "Скважина"

[Григори]

Доброго времени суток, товарищи форумчане. Написал на досуге программу для насосных станций с задачей поддержания заданного давления.
Постарался сделать решение хоть немного универсальным. Прошу оценить :p
Выполнено на FBD и ST

Критика и идеи по улучшению приветствуются!

Исходник и самописное "руководство" прилагаю

[Сергей0308]

Доброго времени суток, товарищи форумчане. Написал на досуге программу для насосных станций постоянного давления.
Постарался сделать решение хоть немного универсальным. Прошу оценить :p
Выполнено на FBD и ST

Критика и идеи по улучшению приветствуются!

Исходник и самописное "руководство" прилагаю

Да, прикольно написали, постоянного тока звучит лучше, в смысле, может поддержания заданного давления?

[Григори]

Да, прикольно написали, постоянного тока звучит лучше, в смысле, может поддержания заданного давления?

Да, согласен, поддержание заданного давления звучит куда гармоничнее

[kondor3000]

Термосопротивление 50М даёт погрешность до +/- 10-15 градусов. Рекомендуется использовать Pt1000

А мгновенный расход надо измерять каждую секунду, а не раз в минуту.

[FPavel]

Предлагаю улучшения:
- сброс выполнять не по лог.1, а по фронту - чтобы сброс не "зависал"
- по аварии - останавливать алгоритм управления - если датчик неисправен, то ПЧВ просто максимально раскрутит насос, а ТЭН перегреет ёмкость
- ошибки, останавливающие работу сделать с фиксацией
- сделать диагностический вывод со сменяемыми сообщениями об ошибках
- т.к. команда на пуск, сброс ошибок и что-то ещё поступают по цифровому интерфейсу, то есть смысл контролировать его состояние (обрыв) и останавливать работу. Контроль осуществлять по изменению какого-нибудь числа, специально изменяемого и присылаемого из Master-устройства.

[Сергей0308]

Термосопротивление 50М даёт погрешность до +/- 10-15 градусов. Рекомендуется использовать Pt1000

А мгновенный расход надо измерять каждую секунду, а не раз в минуту.

Каждую секунду не получится, там счётчик с импульсным выходом, не получится обновлять расход быстрей периода следования импульсов, может доходить до нескольких десятков секунд(например у нас), короче много раз подобные расходомеры обсуждали на форуме, последний раз подобное упоминалось не далее как вчера в соседней теме, короче, предлагаю вычислять(подсчитывать) период следования импульсов в циклах программы, фиксировать значение по фронту сигнала, затем, зная время цикла программы, переводить это в период, затем, зная вес импульса с импульсного выхода, переводить это в расход, короче, я это примерно так вижу, в плане вычисления и обновления значения расхода!
В плане температуры поставить ТРМ200(сейчас 2ТРМ0), к нему подключить датчик температуры 50М и какой-нибудь ещё наиболее важный параметр(на второй вход) вывести для отображения на приборе, а по сетевому интерфейсу считывать значения с помощью ПР200.

https://owen.ru/product/2trm0

[Григори]

Предлагаю улучшения:
- сброс выполнять не по лог.1, а по фронту - чтобы сброс не "зависал"
- по аварии - останавливать алгоритм управления - если датчик неисправен, то ПЧВ просто максимально раскрутит насос, а ТЭН перегреет ёмкость
- ошибки, останавливающие работу сделать с фиксацией
- сделать диагностический вывод со сменяемыми сообщениями об ошибках
- т.к. команда на пуск, сброс ошибок и что-то ещё поступают по цифровому интерфейсу, то есть смысл контролировать его состояние (обрыв) и останавливать работу. Контроль осуществлять по изменению какого-нибудь числа, специально изменяемого и присылаемого из Master-устройства.

-Насчет ПЧВ, по проекту предусмотрено, что будет настройка реакции на обрыв и внешний отказ с выходом на безопасную частоту.
-Ошибки с фиксацией, вы имеете ввиду реализовать их логику на SR-триггерах?
-Насчет диагностического вывода, можно наверное запариться, но на практике конечный пользователь даже не поймет, как этим пользоваться)
-Прекращать работу ПЧ при обрыве связи, в данном случае, боюсь сомнительно, тк логика исходит из концепции постоянно запущенного ПЧ

Пока из собственных мыслей приходит в голову реализовать критическое состояние "замерзание датчика давления", чтобы от него ПЧ тоже вставал

Описание объекта: Скважина в 40-50 км от базы, которая должная снабжать водой 2-3 поселка

[Григори]

Каждую секунду не получится, там счётчик с импульсным выходом, не получится обновлять расход быстрей периода следования импульсов, может доходить до нескольких десятков секунд(например у нас), короче много раз подобные расходомеры обсуждали на форуме, последний раз подобное упоминалось не далее как вчера в соседней теме, короче, предлагаю вычислять(подсчитывать) период следования импульсов в циклах программы, фиксировать значение по фронту сигнала, затем, зная время цикла программы, переводить это в период, затем, зная вес импульса с импульсного выхода, переводить это в расход, короче, я это примерно так вижу, в плане вычисления и обновления значения расхода!
В плане температуры поставить ТРМ200(сейчас 2ТРМ0), к нему подключить датчик температуры 50М и какой-нибудь ещё наиболее важный параметр(на второй вход) вывести для отображения на приборе, а по сетевому интерфейсу считывать значения с помощью ПР200.

https://owen.ru/product/2trm0

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

[Григори]

Термосопротивление 50М даёт погрешность до +/- 10-15 градусов. Рекомендуется использовать Pt1000

А мгновенный расход надо измерять каждую секунду, а не раз в минуту.

Проходил, была погрешность 32 градуса один раз. Но 50М очень дешевые, и объяснить, что АЦП ПРки не может адекватно проскалировать его, не вышло. Пришлось идти на компромисс, добавил возможность минимизации параметрами А и Б
Как думаете, что если сделать блочок для выбора датчика, который от значения целого числа будет на нужный выход транслировать сопротивление и к каждому выходу подцепить свой макрос (PT100/1000, 50М и др)?

Насчет расхода, стоят в основном счетчики с весом импульса 0.1м3/1м3 при среднем расходе 7-15 м3/ч. Но реализована запись времени расчета с облака/скады. Во многих скважинах итог до 100 импульсов импульсов за сутки(Рекордные цифры - 15 импульсов сутки, то есть 1.5 куба)

[petera]

Взял бы датчик KTY81/110,112, Датчик температуры -55…+150°C, Rпри25°C=1кОм±1%
макрос для ОЛ есть под него
для поддержания микроклимата в шкафу самое то
сам пользуюсь для таких случаев
в чипе и дипе копейки стоит

[kondor3000]

Проходил, была погрешность 32 градуса один раз. Но 50М очень дешевые, и объяснить, что АЦП ПРки не может адекватно проскалировать его, не вышло. Пришлось идти на компромисс, добавил возможность минимизации параметрами А и Б
Как думаете, что если сделать блочок для выбора датчика, который от значения целого числа будет на нужный выход транслировать сопротивление и к каждому выходу подцепить свой макрос (PT100/1000, 50М и др)?

Насчет расхода, стоят в основном счетчики с весом импульса 0.1м3/1м3 при среднем расходе 7-15 м3/ч. Но реализована запись времени расчета с облака/скады. Во многих скважинах итог до 100 импульсов импульсов за сутки(Рекордные цифры - 15 импульсов сутки, то есть 1.5 куба)

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

Так же не понятно, пишите вес импульса 0.1 м3, а задаёте в целочисленных)))

Решение с временем и датой из ПР200, тоже не универсальное. На ПР103, ПР205 работать не будет, нужно время и дату брать из ФБ.

[Григори]

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

Так же не понятно, пишите вес импульса 0.1 м3, а задаёте в целочисленных)))

Решение с временем и датой из ПР200, тоже не универсальное. На ПР103, ПР205 работать не будет, нужно время и дату брать из ФБ.

Датчик не для микроклимата, а температуры в павильоне. Чтобы денежки на электричестве экономить)
Решений по температуре масса, но убеждение не мой конек оказался)

задание в целочисленных для экономии, писал программы под некоторые объекты, где был полный фарш из 4 счетчиков, ПЧ, охраны 3 зданий и температур. Память сетевых переменных заполнялась под 100%, пришлось изворачиваться так

А можно подробнее насчет неуниверсальности решения с временем?

[FPavel]

У Овен уже три поколения ПР, и некоторые решения не будут работать с другим поколением.

Например, переменные системного времени у ПР200 и ПР205 по разному определяются, в ПР205 возможно определить обрыв связи со Slave Modbus (например, ПЧВ), а в ПР200 - нет такой возможности.
С ПР других производителей совсем никакой совместимости!

Много в жизни несоответствий...

Я бы и не переживал. Решение для проектного устройства работает - это и есть критерий применимости.

[kondor3000]

А можно подробнее насчет неуниверсальности решения с временем?

У ПР200 встроенные секунды, минуты, часы и дата, у ПР103 и 205, эти переменные надо создавать самому, но в эмуляции ничего не работает.
Посмотрите вот это, варианты для новых и старых ПР. Работает и в эмуляции. Последние ФБ работают вообще без входа и выдают время и дату.
Дата, Время и День недели через DT с 2000г. (и с 1970г.)____________ https://owen.ru/forum/showthread.php?t=40116#4

[Сергей0308]

У ПР200 встроенные секунды, минуты, часы и дата, у ПР103 и 205, эти переменные надо создавать самому, но в эмуляции ничего не работает.
Посмотрите вот это, варианты для новых и старых ПР. Работает и в эмуляции. Последние ФБ работают вообще без входа и выдают время и дату.
Дата, Время и День недели через DT с 2000г. (и с 1970г.)____________ https://owen.ru/forum/showthread.php?t=40116#4

А в ПР они работают?
В смысле, если в ПР они работают, то мне этого достаточно!

[Рогов Алексей]

Добрый день!

В случае, если в паспорте глубинного насоса написано: ПЧВ не применять! прошу на суд общественности свой проект
1. Использованы трансформаторы тока - очень удобная и не дорогая штука
2. Реле контроля фаз электрически подключено после контактора - ещё одна возможность контролировать состояние контактора
3. Часы и энергонезависимый архив сделаны с помощью примеров с форума - благодарность форумчанам
4. Испытано в поле
5. Можно применить для компрессоров, двигателей и прочего оборудования
6. В общем универсальное устройство допускового контроля с тремя попытками - программа повторного включения78984

Спасибо!

[kondor3000]

Добрый день!

В случае, если в паспорте глубинного насоса написано: ПЧВ не применять! прошу на суд общественности свой проект
В общем универсальное устройство допускового контроля с тремя попытками - программа повторного включения78984
Спасибо!

К вашему проекту надо инструкцию по запуску))) Удалось только в эмуляции, на пару секунд запустить работу и всё, а так одни ошибки постоянно выдаёт.

[Рогов Алексей]

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