ФБ на ST ротация насосов

Вид для печати

Показывать 40 сообщений этой темы на одной странице

08.09.2025, 11:04
kondor3000

Вложений: 2

В последней версии ST перестало работать правильно. В версии 2.10.367 правильно Вложение 85634 в версии Owen Logic2.11.368 не правильно Вложение 85635
функция Min5 должна выдавать 4, а в последней версии выдаёт 2, четвёртая наработка самая маленькая 212410, у остальных одинаковая 222410

Код:

function Min5: udint; //имя функции и тип данных выхода var_input //объявление входных переменных I1,I2,I3,I4, I5 : udint; //входная переменная с типом данных udint end_var var //объявление локальных переменных end_var if I1<=I2 and I1<=I3 and I1<=I4 and I1<=I5 then Min5:=1; elsif I2<=I1 and I2<=I3 and I2<=I4 and I2<=I5 then Min5:=2; elsif I3<=I1 and I3<=I2 and I3<=I4 and I3<=I5 then Min5:=3; elsif I4<=I1 and I4<=I2 and I4<=I3 and I4<=I5 then Min5:=4; elsif I5<=I1 and I5<=I2 and I5<=I3 and I5<=I4 then Min5:=5; end_if end_function
08.09.2025, 18:04
FPavel

Цитата:

Сообщение от kondor3000

В последней версии ST перестало работать правильно. В версии 2.10.367 правильно Вложение 85634 в версии Owen Logic2.11.368 не правильно Вложение 85635
функция Min5 должна выдавать 4, а в последней версии выдаёт 2, четвёртая наработка самая маленькая 212410, у остальных одинаковая 222410

Код:

function Min5: udint; //имя функции и тип данных выхода var_input //объявление входных переменных I1,I2,I3,I4, I5 : udint; //входная переменная с типом данных udint end_var var //объявление локальных переменных end_var if I1<=I2 and I1<=I3 and I1<=I4 and I1<=I5 then Min5:=1; elsif I2<=I1 and I2<=I3 and I2<=I4 and I2<=I5 then Min5:=2; elsif I3<=I1 and I3<=I2 and I3<=I4 and I3<=I5 then Min5:=3; elsif I4<=I1 and I4<=I2 and I4<=I3 and I4<=I5 then Min5:=4; elsif I5<=I1 and I5<=I2 and I5<=I3 and I5<=I4 then Min5:=5; end_if end_function

Собирал подобное на макросе FBD, только реализовывал, как у

Цитата:

Сообщение от capzap

тут алиса утверждает что кот можно доработать предлагает такой

Код:

function Min5: udint; var_input I1, I2, I3, I4, I5: udint; end_var var min_value: udint; min_index: udint := 1; begin min_value := I1; IF I2 < min_value THEN min_value := I2; min_index := 2; END_IF; IF I3 < min_value THEN min_value := I3; min_index := 3; END_IF; IF I4 < min_value THEN min_value := I4; min_index := 4; END_IF; IF I5 < min_value THEN min_value := I5; min_index := 5; END_IF; Min5 := min_index; end_function

вдруг её вариант будет работать во всех версиях

т.е. последовательным сравнением.

Приводить здесь не буду, т.к. исходная задача может пострадать от учёта наработки, т.к. по её условию из-за перегрева насоса требуется чередование через 10 минут.
А если какой-то насос заменят на новый с 0 минут наработки, то он первый и сломается.

Думаю, что тут будет востребован инкремент номера текущего насоса с учётом его готовности. Если не готов, то ещё прибавить 1, и опять проверить. Т.е. последовательно 4 проверки (чтобы на следующем цикле вернуться к следующему после только что остановленного).
С учётом необходимости паузы в работе насоса, каждому насосу в конце 10-минутки присваивать по таймеру признак "не готов", который сбросится через заданную паузу.

Может ещё детали по мере реализации возникнут, но это уже забота новичка, который никого не трогал и вдруг возникла задача.
08.09.2025, 18:37
Валенок

to FPavel
kondor3000'у не нужно как-то решить эту задачу. Он говорит что в прошивке ПР грубый косяк. Говорит очень обтекаемо и осторожно - типа перестало работать правильно.
Capzap выше уже сказал тоже (в другой ветке походу)
Я просто говорю как есть (чего стеснятся-то за свои деньги) - авторы прошивки 368 просрали работу со стеком для функций (во всяком случае в эмуляции). Положили параметры для функции в одном порядке, в самой функции взяли в другом. Точнее в прямом, т.к. стек - LIFO а не FIFO

Пробуйте снаружи элементарщину

Код:

function pack: udint; var_input b0: bool; b1: bool; b2: bool; b3: bool; end_var u.0 := b0; u.1 := b1; u.2 := b2; u.3 := b3; end_function
08.09.2025, 19:54
FPavel

Цитата:

Сообщение от Валенок

to FPavel
kondor3000'у не нужно как-то решить эту задачу. Он говорит что в прошивке ПР грубый косяк. Говорит очень обтекаемо и осторожно - типа перестало работать правильно.
Capzap выше уже сказал тоже (в другой ветке походу)
Я просто говорю как есть (чего стеснятся-то за свои деньги) - авторы прошивки 368 просрали работу со стеком для функций (во всяком случае в эмуляции). Положили параметры для функции в одном порядке, в самой функции взяли в другом. Точнее в прямом, т.к. стек - LIFO а не FIFO

Да, уже видел в соседней теме "Фичи и баги Owen Logic" аналогичное подтверждение бага.

Мне показалось, что kondor3000 проверял причины неработоспособности решения для 5 насосов и обнаружил баг.
И именно поэтому, я и не согласился с тем решением-подходом учитывать наработку. Это касается не бага Owen Logic, а самого подхода, алгоритма.

И мне не совсем понравилась реализация функции Min5 - она нерасширяемая. Гораздо удобнее её решать последовательным сравнением с каждым элементом по очереди. Но после пересмотра алгоритма управления эта функция не будет использоваться в программе, поэтому моя вкусовщина уже ни на что не влияет.

А вообще, у той программы
https://owen.ru/forum/showthread.php...l=1#post471287
масса недочётов:
- нет обработки неисправности датчиков температуры
- нет обработки неисправности ПРМ
- нет фиксации неисправностей на триггерах до нажатия кнопки "Сброс сигнализации", что при неустойчивой неисправности будет "дёргать" насос
09.09.2025, 09:49
Валенок

Цитата:

Сообщение от FPavel

Гораздо удобнее её решать последовательным сравнением с каждым элементом...

.. массива в цикле

Цитата:

Сообщение от FPavel

.. эта функция не будет использоваться в программе,..

если задача - "на работу самого отдохнувшего, на отдых самого уставшего" без этой функции или по другому реализованного этого же функционала не обойтись. Если нужен простой и рабочий как молоток код.
09.09.2025, 12:16
witalexxx

Как раз и была задача на работу самого отдохнувшего и на отдых самого уставшего из пяти насосов. А по вопросу: "А вообще, у программы https://owen.ru/forum/showthread.php...l=1#post471287
масса недочётов: - нет обработки неисправности датчиков температуры, - нет обработки неисправности ПРМ, - нет фиксации неисправностей на триггерах до нажатия кнопки "Сброс сигнализации", что при неустойчивой неисправности будет "дёргать" насос".
Поясню - не было времени сделать быстро и нормально, так как по закону подлости в пятницу я добавляв в программу переменные для вывода на экран, и в пятницу (выход обновления) пришлось ехать на объект и перезаливать программу в ПР-200, и как назло, эта проблема с прошивкой, сохранял изменения в новой версии. А в субботу аварийная ситуация на объекте, насосы не ротировались, перегрев, пришлось на коленях контроль температуры делать. Вот и думай, пользоваться ли дальше такими котроллерами. Да и был баг с той прошивкой, входы DI1,2,3 вообще +24 не видели, три раза с ПР-200 пришлось питание снимать, а так совсем не управлялся, ни паузы, ни сброса, ни готовности.
09.09.2025, 12:27
witalexxx

Цитата:

Сообщение от In_Da_Cher_A

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

Глупости пишете, никто никаких претензий не предъявляет, осктитесь, здесь вопрос о баге и есть этому подтверждение на форуме. Вы по себе о других не судите пожалуйста и хамить последнее дело, уважаемый. У меня 42 дня все корректно было, а тут это обновление и стечение обстоятельств с его установкой.
09.09.2025, 18:56
FPavel

Вложений: 1

witalexxx, исключительно по моему мнению, нужно иначе организовывать структуру программы - изначальная проблема только в этом. Структура программы позволяет применить механистический (почти бездумный) подход к написанию почти половины программы - защиты и блокировки. А рабочие алгоритмы выполнить в конце холста. Тогда даже при неправильном алгоритме - блокировки защитят оборудование, пока программист будет судорожно исправлять и дополнять рабочую часть.

Пока готовлю статью в своём бложике. Остановился из-за того, что обновил Owen Logic до версии 2.11.368.0 (с багом в ST) - не могу откатить исходники в младшую версию, жду обновления.

Суть подхода в разделении всей системы на независимые подсистемы и их общую часть. В вашем случае будет 6 подсистем (5 насосов и общая часть). Далее, в Exel готовлю стандартные переменные (так быстрее, чем руками набирать в Owen Logic) - каждая система содержит наборы по 16 бит:
- состояние (включён, выключен, в аварии, готов к работе и пр.)
- состояние предупредительной сигнализации
- состояние защитной блокировки
- команды из вышестоящей системы (панели оператора, SCADA, OwenCloud).
Получается всего 6 подсистем х 4 набора х 16 бит = 384 переменных. Конечно же тут Exel - незаменим.
Также добавляются группы переменных:
- для обмена с экраном
- для привязки к аппаратной части ПР (состояние ПРМ, наличие связи с ПЧВ, состояние аналоговых входов)
- входы
- выходы

После этого с участием этих переменных создаётся программа - защиты и рабочие алгоритмы.

По мере набора программы выясняется какие переменные для настройки потребуются и они отдельно прописываются в файл импорта сетевых переменных.
А пока эти места пропускаются.
Настройки удобно хранить в сетевых переменных - они энергонезависимы, позволяют редактироваться и с экрана и с панели (SCADA / OwenCloud), получают начальное значение.
Также в сетевые переменные отправляются текущие состояния (измеренные температуры, давления, упакованные биты состояний-сигнализации-блокировок и пр.)

Когда вся программа готова - окончательно приводится в порядок файл импорта сетевых переменных. Exel помогает вычислить адреса и заполнить дублирующиеся поля.

Импорт сетевых переменных их расстановка по экрану.

Структура программы позволяет сразу реализовать защиты. Отрицательный эффект в появлении множества переменных, который диалектически приводит к применению Exel и в целом ускоряет работу.

Не слежу за развитием ПР200, ещё недавно для инициализации начальным значением для сетевых переменных требовались дополнительные макросы - возможно уже это улучшили.

Вчерне этот рассказ иллюстрируется тремя последовательными этапами программы-примера: 2 насоса работают на одну магистраль.
Это просто иллюстративный пример, подозреваю, что на оборудовании не заработает.

Достоинство методики, на мой (авторский) взгляд:
1 механистический подход к значительной части программы - т.е. защиты и блокировки 100% не будут пропущены из-за спешки, т.к. реализуются в самом начале
2 сама программа разделяется на почти независимые разделы, а переменные служат для связи между ними. Причём, переменные имеют одинаковый префикс и механистически только по признаку этого префикса подключаются к макросам на холсте
3 при необходимости расширения программы - переменные состояния и блокировки уже объявлены и ждут лишь переименования под ситуацию

В архиве файлы для каждого этапа программы:
- создание множества стандартных переменных (получение образца, черновое массовое создание "протягиванием" ячеек в Exel, переименование под конкретную задачу)
- создание программы (механистическое создание части без рабочих алгоритмов, "интеллектуальное" создание рабочих алгоритмов, завершение кода после импорта сетевых переменных)
- создание множества сетевых переменных (получение образца, заполнение по мере разработки программы, уточнение адресов и дублирующихся полей)

Вложение 85681

Показывать 40 сообщений этой темы на одной странице