ВОПРОС-ОТВЕТ (отвечаем на простые вопросы от новичков)

[Cs-Cs]

Уж не знаю, насколько это "медленней" по сравнению с работой со входами/выходами через байты - но подозреваю, что несущественно.
Но при этом вы не привязаны к расположению входов/выходов в структурах и можно в любой момент "отключить" физические входы/выходы для, например, 'эмуляции процесса

АБСОЛЮТНО соглаасен! Я так делаю прям вот всегда! У меня этому даже кусок статьи посвящён (рекомендую прочитать, без шуток): https://cs-cs.net/technologii-testir...a-plk#4_____io
Только я НЕ использую прямую адресацию, а разбираю в таких переменных битовые маски и именую переменные понятным текстом. Вот так:

hwBtnLgt1EPrihojMain			: BOOL;		(* W2.I1: Кнопки LT-41: 1 Этаж Прихожая Общий *)
hwBtnLgt1EPrihojTrackShkaf		: BOOL;		(* W2.I2: Кнопки LT-42: 1 Этаж Прихожая Трек у Шкафа *)
hwBtnLgt1EPrihojZerkalo			: BOOL;		(* W2.I3: Кнопки LT-43: 1 Этаж Прихожая Зеркало *)
hwBtnLgt1EPrihojSpotDver		: BOOL;		(* W2.I4: Кнопки LT-44: 1 Этаж Прихожая Споты Дверь *)
hwBtnLgt1EPrihojFuncShkaf		: BOOL;		(* W2.I5: Кнопки LT-45: 1 Этаж Прихожая Функциональный у Шкафа *)
hwBtnLgt1EPrihojIgrDecor		: BOOL;		(* W2.I6: Кнопки LT-46: 1 Этаж Прихожая/Игровая Декор *)
hwBtnLgt1EZakutok				: BOOL;		(* W2.I7: Кнопки LT-47: 1 Этаж Закуток *)
hwBtnLgt1EMicroKabinet			: BOOL;		(* W2.I8: Кнопки LT-48: 1 Этаж Микрокабинет *)
hwBtnLgt1EIgrMain				: BOOL;		(* W2.I9: Кнопки LT-49: 1 Этаж Игровая Общий *)
hwBtnLgt1EIgrTrack				: BOOL;		(* W2.I10: Кнопки LT-50: 1 Этаж Игровая Трек Окно *)


hwBtnLgt1EPrihojMain			:= W2_DI32.0;	(* W2.I1: Кнопки LT-41: 1 Этаж Прихожая Общий *)
hwBtnLgt1EPrihojTrackShkaf		:= W2_DI32.1;	(* W2.I2: Кнопки LT-42: 1 Этаж Прихожая Трек у Шкафа *)
hwBtnLgt1EPrihojZerkalo			:= W2_DI32.2;	(* W2.I3: Кнопки LT-43: 1 Этаж Прихожая Зеркало *)
hwBtnLgt1EPrihojSpotDver		:= W2_DI32.3;	(* W2.I4: Кнопки LT-44: 1 Этаж Прихожая Споты Дверь *)
hwBtnLgt1EPrihojFuncShkaf		:= W2_DI32.4;	(* W2.I5: Кнопки LT-45: 1 Этаж Прихожая Функциональный у Шкафа *)
hwBtnLgt1EPrihojIgrDecor		:= W2_DI32.5;	(* W2.I6: Кнопки LT-46: 1 Этаж Прихожая/Игровая Декор *)
hwBtnLgt1EZakutok				:= W2_DI32.6;	(* W2.I7: Кнопки LT-47: 1 Этаж Закуток *)
hwBtnLgt1EMicroKabinet			:= W2_DI32.7;	(* W2.I8: Кнопки LT-48: 1 Этаж Микрокабинет *)
hwBtnLgt1EIgrMain				:= W2_DI32.8;	(* W2.I9: Кнопки LT-49: 1 Этаж Игровая Общий *)
hwBtnLgt1EIgrTrack				:= W2_DI32.9;	(* W2.I10: Кнопки LT-50: 1 Этаж Игровая Трек Окно *)

Мои методы и технологии описаны в статье. Берите все на вооружение!
Там ещё и технология теестирования IO и обработки ошибок IO есть!

[1exan]

АБСОЛЮТНО соглаасен! Я так делаю прям вот всегда! У меня этому даже кусок статьи посвящён (рекомендую прочитать, без шуток): https://cs-cs.net/technologii-testir...a-plk#4_____io
Только я НЕ использую прямую адресацию, а разбираю в таких переменных битовые маски и именую переменные понятным текстом. Вот так:
[CODE]hwBtnLgt1EPrihojMain : BOOL; (* W2.I1: Кнопки LT-41: 1 Этаж Прихожая Общий *)
hwBtnLgt1EPrihojTrackShkaf : BOOL; (* W2.I2: Кнопки LT-42: 1 Этаж Прихожая Трек у Шкафа *)
hwBtnLgt1EPrihojZerkalo : BOOL; (* W2.I3: Кнопки LT-43: 1 Этаж Прихожая Зеркало *)
hwBtnLgt1EPrihojSpotDver : BOOL; (* W2.I4: Кнопки LT-44: 1 Этаж Прихожая Споты Дверь *)

А в чём смысл давать имя только байту, а потом обращаться к его битам (именованные константы, как я понял)?
Почему не именуешь сразу отдельные биты - в экселе ведь это тоже просто сделать?

[Cs-Cs]

А в чём смысл давать имя только байту, а потом обращаться к его битам (именованные константы, как я понял)?
Почему не именуешь сразу отдельные биты - в экселе ведь это тоже просто сделать?

Не, не именованные константы. Если не сложно - лучше почитать мою статью. Я там подробно всё расписал как раз для вставки на форум.
Шаги моей задумки такие:
1. Много переменных в программах ПЛК - булевые: Дискретные датчики, статусы сигналов, выходы на реле, контакторы.
2. Привязка переменных в ПЛК делается по разному. Встроенные входы-выходы можно привязать в конфигурации (причём одни сразу булевые, а другие - байтами по 8 входов или выходов), а IO модулей ввода-вывода вообще читается по 16 бит или по 32 бита (смотря какие модули используем0.
Всё это приводит к чёртовому зоопарку: что-то объявлено в конфигурации ПЛК, что-то используется сразу в коде типа "DIModbus.4" без понятных имён, что-то формируется ещё где-то.
3. Меня выбесило то, что нет системности, где привязываются ВСЕ каналы ввода-вывода, и я сделал так:
а) Объявляю в Глобальных переменных все нужные названия переменных ввода-вывода ПОНЯТНЫМИ именами.
б) В конфигурации ПЛК объявляю групповые переменные для каналов опроса - битовые маски.
в) В задаче (в одном месте) TaskIO разбираю битовые маски и привязываю их там к моим переменным.
г) В остальных задачах обращаюсь к своим понятным и красивым переменным.
Благодаря этому привязка IO происходит ТОЛЬКО в одном месте программы, она наглядная, и там можно что-то легко поменять.
А в программе я оперирую понятными переменными типа hwStatusUPS, hwStatusL1 и так далее, что делает код читаемым и избавляет от магических чисел (с которыми я на форуме ОВЕНа сталкиваюсь больше, чем за весь стаж программирования).

В общем, настоятельно рекомендую почитать мою статью! Заодно новых методов разработки и отладки можно там набраться!

[1exan]

при смене платформы же легче в новой конфигурации задать только одно имя, чем прописывать каждый бит(буль) отдельно, даже если это в эксель

Возможно, но в конечном итоге всё рано где-то придётся указывать конкретный номер бита, поэтому я большой разницы не вижу

[Cs-Cs]

Возможно, но в конечном итоге всё рано где-то придётся указывать конкретный номер бита, поэтому я большой разницы не вижу

Пожалуйста найди час времени (за обедом, перед сном) прочитать мою статью. Тогда и обсудим.
Я готов учиться у самых лучших. Сейчас я не вижу, чему мне учиться: прямая адресация и непонятные имена переменных - это полшага до магических чисел, за которые надо наказывать!

[МихаилГл]

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

[1exan]

Пожалуйста найди час времени (за обедом, перед сном) прочитать мою статью. Тогда и обсудим.
Я готов учиться у самых лучших. Сейчас я не вижу, чему мне учиться: прямая адресация и непонятные имена переменных - это полшага до магических чисел, за которые надо наказывать!

DI_5 не более непонятное имя, чем W1_DIA.0:
DI_5 - это дискретный вход №5, что по-моему, очевидно следует из его имени, и W1_DIA.0 - это тоже дискретный вход №5, что уже не совсем очевидно, и поэтому наверное дополнительно указывается в комментарии

Я лично не вижу ничего плохого в прямой адресации при работе с физическими входами/выходами

[1exan]

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

Так все разговоры только о способе организации этой прокладки и идут

[Easy_Enemy]

ни чего не понял, Flap это структура, начинающаяся с REAL, как Вы присваиваете ей(конкретно реалу) байт с дискретными переменными управления на открытие и закрытие?

Прошу прощения, не правильно написал изначально, и народ запутал, уже голова не варила: заслонки трехпроводные, двухфазные, без отслеживания положения. Собственно, описанное с использованием REAL - были функции отслеживания текущего положения заслонки по времени ее работы. Еще раз - пардон

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

Поясните, пожалуста, не вкурил.. Я создаю некую систему, пусть ту же вентиляху. Одно из свойств системы - те же заслонки. В функции карты (соответствие входов/выходов и переменных в массиве для обработки 1 блоком) собственно все раскидываю. При каких условиях может начаться апокалипсис?
Обзываю входы в конфигураторе на первых порах, для тестов, чтоб не запутаться.

Только я НЕ использую прямую адресацию, а разбираю в таких переменных битовые маски и именую переменные понятным текстом.

Вот тут как раз и случился затык, от чего и полез на форум народ пытать. Есть выход (пусть QX1.0, запихал его в переменную (Пусть DO1). Далее, для того, чтобы можно было обработать в цикле, присваиваем этот выход в переменную массива, пусть Sys[1]._Do1. Соответственно, для всей системы была написана функция карты (Sys[1]._Do1:=DO1) (делаю так для всех систем, а потом объявляю один раз при инициализиции). При управлении "без лишнего" - работает. Включается-выключается и через массив и через прямую. При управлении, как было, через CASE работает только, если мы пишем непосредственно в переменную выхода (прямую, DO1). Может я чего не понимаю, конечно.. А то и многое) В обработке через условия (CASE/IF), если запишем в переменную массива (Sys[1]._Do1), видно, что значение ее меняется, но не присваивается в D01. Поэтому и разродилась идея уйти в обычные дискретные выходы, так как нет "прослойки", в виде "DO...", а можно сразу, через адресацию сунуть все в эррей. Ну, как бэ - да, во-первых, ADR на %QX сделать не удастся, во-вторых - нужны 2 переменные (указатель на байт и указатель на бит), но, и черт с ним, не самая большая проблема.

Статью почитаю, спасибо)

[1exan]

...
Есть выход (пусть QX1.0, запихал его в переменную (Пусть DO1). Далее, для того, чтобы можно было обработать в цикле, присваиваем этот выход в переменную массива, пусть Sys[1]._Do1. Соответственно, для всей системы была написана функция карты (Sys[1]._Do1:=DO1)
...

Прочитал два раза, ничего не понял

Посмотрел ещё раз ваш проект:
Вы объявляете выходы в конфигурации:
изображение_2024-02-15_220617706.png
а потом здесь зачем то читаете их состояние

Ven[1].Flap.Open:=Flap1Open;
Ven[1].Flap.Close:=Flap1Close;

Вы ничего не путаете?