СПК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 осталась.

[capzap]

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

owen.pngэта конструкция и эта owen.png не имеют отличий и не нарушают Вашу концепцию непринятия портянок

Во-вторых, эти POU обрабатывают разные входные данные и код в них разный, и речь вовсе не о подстраховке.

owen.pngвыделенные строки не имеют отличий

В-третьих ...

а я ни где не утверждал что именно это поможет. Я просто не вижу потребности делать вещи лишенные смысла, такие как входные переменные выполняют свою задачу, они потому и входные что их менять нельзя, только читать, зачем в этом проекте PERSISTENT, инициализация VAR foo : BOOL := TRUE END_VAR вполне себе заменяет ПОУ с IF NOT xFlag THEN foo := TRUE; xFlag := TRUE; END_IF и т.д.и т.п.

[rch]

owen.pngэта конструкция и эта owen.png не имеют отличий и не нарушают Вашу концепцию непринятия портянок

О том Вам и говорил в предыдущих постах.

owen.pngвыделенные строки не имеют отличий

Этот код:

IF SpL11_PurgePeriod.tmVal <> PersistentVars.SpL11_PurgePeriod THEN
	IF (SpL11_PurgePeriod.tmVal>=GVL.PurgePeriod_MIN) AND (SpL11_PurgePeriod.tmVal<=GVL.PurgePeriod_MAX) THEN
		PersistentVars.SpL11_PurgePeriod:= SpL11_PurgePeriod.tmVal;
	ELSE
		SpL11_PurgePeriod.tmVal:= PersistentVars.SpL11_PurgePeriod;
	END_IF
	PLC_PRG.SpL11_PurgePeriod:= PersistentVars.SpL11_PurgePeriod;
	ModbusTcpData.SpL11_PurgePeriod.tmVal:= PersistentVars.SpL11_PurgePeriod;
END_IF

отличается от этого:

IF SpL11_PurgePeriod.tmVal <> PersistentVars.SpL11_PurgePeriod THEN
	IF (SpL11_PurgePeriod.tmVal>=GVL.PurgePeriod_MIN) AND (SpL11_PurgePeriod.tmVal<=GVL.PurgePeriod_MAX) THEN
		PersistentVars.SpL11_PurgePeriod:= SpL11_PurgePeriod.tmVal;
	ELSE
		SpL11_PurgePeriod.tmVal:= PersistentVars.SpL11_PurgePeriod;
	END_IF
	PLC_PRG.SpL11_PurgePeriod:= PersistentVars.SpL11_PurgePeriod;
	ModbusRtuData.SpL11_PurgePeriod.tmVal:= PersistentVars.SpL11_PurgePeriod;
END_IF

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

а я ни где не утверждал что именно это поможет.

Я собственно и не ожидаю чудесного решения проблемы.

[CODE]Я просто не вижу потребности делать вещи лишенные смысла, такие как входные переменные выполняют свою задачу, они потому и входные что их менять нельзя, только читать, зачем в этом проекте PERSISTENT, инициализация VAR foo : BOOL := TRUE END_VAR вполне себе заменяет ПОУ с IF NOT xFlag THEN foo := TRUE; xFlag := TRUE; END_IF и т.д.и т.п.[/QUOTE]
Соглашусь с замечанием. Хотя технически входные переменные на время выполнения POU являются для него локальными переменными, и изменение их возможно из кода POU. Проблема в том, что изначально эти переменные не были VAR_INPUT. Но так как понадобилось изменять их из смежных POU - появилось такое неизящное решение. Сами входные переменные привязаны в соотнесении входов Modbus RTU/TCP Slave. А т.к. мне необходимо, чтобы при неверном значении, полученном по Modbus, в регистр писалось верное значение (для последующего чтения извне), то понадобилась возможность изменять внутреннюю переменную POU привязанную к регистру Modbus. Собственно так они и стали VAR_INPUT. Можно сделать их глобальными и замечание снимется. Но как писал выше, изменение кода в таком ключе основной проблемы не снимает.

По ссылке проект без VAR_INPUT и весь код полностью в одном POU https://disk.yandex.ru/d/4UUg_wj09z8FyA