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

[FPavel]

В последней версии ST перестало работать правильно. В версии 2.10.367 правильно 1 367 версия.jpg в версии Owen Logic2.11.368 не правильно 1 Версия 368.jpg
функция 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, только реализовывал, как у

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

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-минутки присваивать по таймеру признак "не готов", который сбросится через заданную паузу.

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

[Валенок]

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

[FPavel]

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

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

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

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

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

[Валенок]

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

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

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

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

[witalexxx]

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

[FPavel]

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, переименование под конкретную задачу)
- создание программы (механистическое создание части без рабочих алгоритмов, "интеллектуальное" создание рабочих алгоритмов, завершение кода после импорта сетевых переменных)
- создание множества сетевых переменных (получение образца, заполнение по мере разработки программы, уточнение адресов и дублирующихся полей)

Иллюстация(возможно_с_ошибками).zip