Василий Кашуба, речь о переносе на CodeSys, может не заработать...
Василий Кашуба, речь о переносе на CodeSys, может не заработать...
Для подсчета общего времени наработки такой способ не подойдет - все равно придется запоминать с некоторой дискретностью.
А поскольку уже таймер под это дело заведен - то почему бы и наработку с момента запуска не инкрементировать по сигналу таймера?
Плюсом такого решения можно назвать меньше зависимостей от библиотек.
Аргументированная критика и вопросы всегда приветствуются.
Владимир Ситников в вашем варианте еще переход через ноль придется отслеживать.... Простой счетчик в несколько раз проще, за одним исключением, они зараза все 16-ти разрядные.
На текущий момент наработка сохраняется в RETAIN-памяти.
В описании (в моем посте) я это дополнительно указал. Не думаю, что в алгоритме это нужно указывать.
По поводу циклической записи файлов во внутреннюю память - я противник этого. Т.к. если система работает круглосуточно, то в конечном итоге мы израсходуем ресурс флеш-памяти.
У вас ошибка в алгоритме: если наступит авария, то перестанут запускаться-останавливаться насосы. Даже рабочие.
Вот пример такого состояния (я его сделал через force write для переменных "pump ok", "pump disabled"):
pump_control_fail.png
Видно, что "isRunning=FALSE" для всех насосов, есть 2 нормальных (3ий и 4ый), но система думает, что "TOO_FEW_PUMPS".
Перерисовал алгоритм (с сохранением этой же ошибки).
На перерисованной картинке эта проблема более заметна: заход в "запуск-останов" происходит только в безошибочном состоянии.
PumpControl.png
Программа тут: http://drakon.su/programma_is_drakon (на странице http://drakon.su/ ссылка на учебник и т.п.)