"Преобразование" указателей на тип FB или как определить тип FB в runtime

Привет коллеги!
В общем задача относится не столько к ПЛК 73, как к CDS2.3 в целом.
Использую в своих проектах такой механизм, как "настраиваемые входы". Не в прямом смысле, конечно.
Например, есть несколько датчиков. Но в одной компоновке оборудования одни ИСПОЛЬЗУЮТСЯ, в другой - эти же НЕ используются.
Понятно, что если датчик отключен, то будет ошибка (программно обрабатываю, разумеется). Поэтому в настройках можно включать и отключать датчики.
С датчиками все ОЧЕНЬ легко - структура с флагом "использовать = true/false" и переменная - указатель на вход, где брать значение.
При запуске инициализируем в соответствии с настройками из энергонезависимой памяти и вперед...
Даже показывать не буду.

Для дальнейшего развития беседы следующая аксиома: сам процесс одинаково протекает, "компоновка оборудования" означает что в одном случае нагреваем и кипятим в одной посудине, а в другом - в 2х разных, вот отсюда 1-2 датчика и 1-2 нагревателя. А управление абсолютно одинаковое.

Ну и чем дальше в лес, тем толще партизаны.
При очередном апгрейде проекта решил я заморочиться с настраиваемыми выходами. Сделал по полной аналогии с входами.
Идея проста: есть несколько "функциональных выходов", например: 2 нагревателя, 2 выключателя-реле.
В одной компоновке оборудования есть ОБА НАГРЕВАТЕЛЯ и ОБА ВЫКЛЮЧАТЕЛЯ. В другой, например, по одному.
На каждый ТИП выхода свой тип Function Block. В "конфигурационной структуре" задаем типы выходов, указатели на "обработчик" выхода = function block.
Сделал И... УПЕРСЯ в тот факт, что "обработчик выхода" не может быть вызван т.к. типы FB РАЗНЫЕ...

Понимаю, что "привести" (изменить) указатель на FB не получится. Либо за много лет я так и не узнал Как...
Сделал очень сухую выжимку из проекта, точнее сгенерировал примерчик того, что хочу достичь, обозвал все так, чтобы и понятно было по смыслу что происходит.
Буду признателен за подсказку либо как, все-таки, определить какой FB используется и как вызвать разные FB в runtime,
или, как вариант, кто-то может предложит альтернативный механизм конфигурации "набора выходов".

Да, добавлю, чтобы ясность была: понятно, что каждая функция выхода "привязана" к конкретному выходу ПЛК, то есть функция(ВЫХОД) может НЕ использоваться в
изделии (тогда выход не управляется и отключен), но заранее известно к какому выходу какая функция привязана!
Проект во вложении

Шо-то вот мне думается, что в 2.3 такое не будет работать
Вот в 3.5 ещё может быть - там есть явное наследование FBшек.

По теме:
"Преобразование" указателей на тип FB или как определить тип FB в runtime

Как определить что лежит в закрытой коробке?
-прочитать надпись про содержимое коробки

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

Хорошая идея, но, увы, не рабочая. Во всяком случае, с кдс2.3. Поместить в структуру указатель и ТИП FB не проблема - достаточно enum всех возможных типов иметь, кстати, у меня так и сделано, и так реализована настройка входов. Беда в другом - в кдс НЕЛьЗЯ вызвать по «абстрактному» указателю объект.
Однако Вы только что навели меня на интереснейшую мысль: а если в момент проверки в зависимости от этой «надписи» (поле структуры типа enum со значением соответствующего ФБ ) - «типизировать» указатель, присваивая его объявленной переменной - указателю соответствующего типа?? Кдс же не проверяет операции над указателями!!
Обязательно проверю сегодня же! Отпишусь.
Как минимум , ТАКОЙ вариант я еще не проверил, все остальные уже испытаны.

Цитата:

---

Хорошая идея, но, увы, не рабочая. Во всяком случае, с кдс2.3.

---

Ну не смешите

"пихайте адрес в нужный указатель и вызывайте его." - внимательно прочитали? И найдите отличия

Цитата:

---

если в момент проверки в зависимости от этой «надписи» (поле структуры типа enum со значением соответствующего ФБ ) - «типизировать» указатель, присваивая его объявленной переменной - указателю соответствующего типа??

---

Цитата:

---

Поместить в структуру указатель и ТИП FB

---

Тип необязательно. Тип ФБ может содержатся в самом ФБ. Вы же не будете пихать туда адреса левых фб. Только из своего "дерева наследования"

РОДИЛОСЬ:cool:
Спасибо!
Да, код немного усложнился, по отношению к ожиданиям. Но полученный вариант меня устраивает! Учитывая , что выходов таки ограниченное количество - прекрасно выглядит, а главное - компактно обрабатывать получается, да еще и в цикле. Мне особенно нравится, что выходы с одинаковым функционалом - например, нагреватели - устанавливаются (вычисляются) вызовом одного действия.
Во вложении полностью рабочий пример с визуализацией. Тип, ДЕЙСТВИТЕЛЬНО, нафиг не нужен - оставил пока в раздумьях "а вдруг пригодится". Учитывая, что массив изначально индексирован ENUMом - индекс всегда соответствует типу нужного FB и указатель правильный в правильном месте!
Сделал в коде-примере взаимоувязку двух "Органов управления" (как раз исполнительные механизмы - функциональные выходы) ровно так, как в жизни должно примерно происходить, за одним только исключением, что в реальном проекте вместо передачи параметров явно в ФБ использую механизм сообщений.
В общем, кому интересно - тыкайте визуализацию и смотрите "как оно моргает". На valve фантазия кончилась да и время ночь на дворе.
Довольный пошел спать .
Еще раз Большое спасибо, Валенок ! За рулем на бегу не вчитался, очевидно, но мысль, видно, пробралась внутрь сама;)

УТРОМ:

Тему можно закрывать. Кому надо - проект с осмысленным поведением приложен. (outtype смело можно ликвидировать в структуре, если вы используете индексацию массива ENUM, ну или именованными константами индексируете). Уже перетащил ночью в рабочий проект , изумительно работает.