СПК110 [М01] + PersistantVars - некорректное восстановление значений при перезапуске.

[capzap]

Если закомментировать строку

PLC_PRG.SpL11_PurgePeriod:= PersistentVars.SpL11_PurgePeriod;

, то проблема уходит, но она необходима, для того чтобы исключить повторную проверку уставки.

а где комментировали? Во всех трех местах или в какой то одной программе, которая считаете выполняется когда, первой последней ...
в PRG создавать область ввода это как то не профессионально
приоритета выполнения тоже нет, каждый раз может запустится в любой последовательности
в основном в эту переменную идет запись внутри условия, значит условие это выполняется может стоит обратить внимание на смежную переменную

[rch]

в PRG создавать область ввода это как то не профессионально

В CS3.5 я вообще могу убрать/переименовать PLC_PRG, это всего лишь имя POU. Ну и в общем не профессиональность в этой теме обсуждаем...

приоритета выполнения тоже нет, каждый раз может запустится в любой последовательности

Все POU в одной задаче, выполняются последовательно, приоритет не влияет, последовательность выполнения POU всегда одна и та же.

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

Проверено неоднократно в разных комбинациях. В ходе тестов выяснилось, что проблема уходит при отключении стандартного компонента Modbus RTU Slave, при этом ничего не закомментировано.
Делаю вывод, что проблема в нём. Как это происходит - вопрос к разработчикам компонента.

[capzap]

В CS3.5 я вообще могу убрать/переименовать PLC_PRG, это всего лишь имя POU.

я акцентирую не на имя PLC_PRG, а на тип PRG, область входных переменных используется в функциональных блоках и функциях

Все POU в одной задаче, выполняются последовательно, приоритет не влияет, последовательность выполнения POU всегда одна и та же

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

запустите все свои ПОУ в одном PLC_PRG это ни чем не будет отличатся от того что на данный момент, зато конкретно будет ясна последовательность выполнения и как бы Вы не говорили что не поднимать тему об навыках и умениях, но по несколько раз писать одно и тоже только в разных ПОУ это дичь, кто Вас такому научил, это даже на подстраховку не похоже

[rch]

я акцентирую не на имя PLC_PRG, а на тип PRG, область входных переменных используется в функциональных блоках и функциях

Не запрещается использовать VAR_INPUT в POU типа PROGRAM, хотя может и не является типичным. Если вы почитаете справку на CODESYS, то увидите это:https://help.codesys.com/webapp/_cds...rsion=3.5.17.0

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

Это предложение просто для повторяемости результата. По факту у меня всегда с первого раза некорректно восстанавливаются значения. И для размышления, у Евгения Кислова, который отвечал выше, на СПК данная проблема на выложенном мной выше проекте вообще не проявляется, но у него СПК выпущен до октября 2022г.

запустите все свои ПОУ в одном PLC_PRG это ни чем не будет отличатся от того что на данный момент, зато конкретно будет ясна последовательность выполнения и как бы Вы не говорили что не поднимать тему об навыках и умениях, но по несколько раз писать одно и тоже только в разных ПОУ это дичь, кто Вас такому научил, это даже на подстраховку не похоже

Во-первых, в разные POU код проверки разнесён для удобочитаемости, чтобы не было многокилометровых листингов в одном файле (что как раз и есть дичь).
Во-вторых, эти POU обрабатывают разные входные данные и код в них разный, и речь вовсе не о подстраховке.
В-третьих, перенос всего этого кода в один POU не изменяет порядок выполнения никак, т.к. POU в задаче выполняются последовательно в том порядке, в котором они указаны в настройках задачи. Чтобы не быть голословным, сделал вариант (как вы предлагаете), где всё в одном POU (PRG без VAR_INPUT), и как ни странно дичь при восстановлении значений PersistentVars осталась.