"Умное" управление освещением в квартире

[Yegor]

У меня нормально открывается. Так-то респект, конечно. Но код не очень понравился: много условий, деление на POU довольно наивное, кучки данных тут и там. Вообще наличие в коде повторяющихся рисунков текста это верный признак того, что часть кода просится «за скобки» — в отдельные функциональные блоки и типы данных. Дела иначе обстоят в графических языках, но здесь-то текст.

Взять, скажем, MainRoom со 137 строки. Там регулировки яркости идут счётчиками CTUD. И везде в аргументах счётчиков идентичные по своей логике выражения. Так почему не вынести эту логику в свой ФБ на основе того же CTUD, чтобы не писать одну и ту же комбинацию AND/OR/NOT?

Или вот такое:

IF ((R_out=100)AND(G_out=0)AND(B_out=0)AND(Auto)) THEN R_set:=100; G_set:=100; B_set:=0; END_IF;
IF ((R_out=100)AND(G_out=100)AND(B_out=0)AND(Auto)) THEN R_set:=0; G_set:=100; B_set:=0; END_IF;
IF ((R_out=0)AND(G_out=100)AND(B_out=0)AND(Auto)) THEN R_set:=0; G_set:=100; B_set:=100; END_IF;
IF ((R_out=0)AND(G_out=100)AND(B_out=100)AND(Auto)) THEN R_set:=0; G_set:=0; B_set:=100; END_IF;
IF ((R_out=0)AND(G_out=0)AND(B_out=100)AND(Auto)) THEN R_set:=100; G_set:=0; B_set:=100; END_IF;
IF ((R_out=100)AND(G_out=0)AND(B_out=100)AND(Auto)) THEN R_set:=100; G_set:=0; B_set:=0; END_IF;

Это автомат ротации цветов. По достижении одной комбинации уставок задаётся следующая комбинация. Реально суть переключений сводится к этому: state := MAX(1, (state + 1) MOD 7), причём нулевое состояние можно использовать вместо признака Auto. А суть условий сводится к тому, что все условия делятся на 100. В итоге можно обойтись одним условием и обезопасить себя от несоответствий:

IF state > 0 AND R_out MOD 100 = 0 AND G_out MOD 100 = 0 ABD B_out MOD 100 = 0 THEN
    state := MAX(1, (state + 1) MOD 7);
    R_set := SEL(state.0, 0, 100);
    G_set := SEL(state.1, 0, 100);
    B_set := SEL(state.2, 0, 100);
END_IF

И тому подобное. Код надо писать так, чтобы как можно труднее было ошибиться из-за копипаста.