Динамический вызов функций либо FB, и все-таки...

[capzap]

мне вообще не заметно где здесь динамическое выполнение, ладно бы использовалась SysMemAlloc

второе, а почему не написать fbInst := ADR(fbSSTBY);

третье

ПЛК1хх какой нибудь, но только ради CODESYS v3.5

такое невозможно впринципе, а не из-за Вашей религии

[dorofeevms]

Коротко - тута обратного вызова нету. Совсем

Видимо придется смириться. Пока не надоест до конца будут if then писать

мне вообще не заметно где здесь динамическое выполнение, ладно бы использовалась SysMemAlloc

второе, а почему не написать fbInst := ADR(fbSSTBY);

Что касается первого, я же написал, что сам код динамического вызова "в процессе машины состояний" не приведен, тут я лишь написал САМ вызов, чтобы показать что не работает как хотелось бы.
Сама идея проста: в массиве лежат адреса вызова fb (или функций), индекс массива = коду события (или наоборот - как душе угодно), тогда:
адрес_функции := массив[код_события или код_следующего состояния или структура.массив[код_следующего_состояния] ] , ну вот так упрощенно человеческим языком
Ну и далее call (*адрес_функции). Очень близко к этому делаю в C. Бесконечный цикл вызова состояний состоит из 4 строк, обработчик состояния - одна функция/процедура. Модифицировать код - проще некуда (я давно перестал писать с нуля, беру старый проект и переименовываю состояния, если, конечно, суть задачи описывается автоматным программированием). Код события обычно "вычисляю-перевожу" из событий клавиатуры, таймеров и тд в некий int
В C использую enum, как код состояния и индекс массива, и как код события (отдельный enum конечно).

ко-второму: так именно так и написано, только в начале выполнения (при инициализации) в массив состояний заносятся адреса FB, который потом будут выбираться и вызываться через индексы, то есть
fbInst := arStates[1].iActionHandlerPTR как раз и получает ADR(...)
На этапе программирования мы же не знаем адреса FB, поэтому в начале выполнения заполняем массив состояний адресами вызываемых FB.

Вот смотрю, и думаю, а что интересно будет, если fbInst объявить тоже как DWORD ?... вечером проверю.

А невозможно ЧТО (про плк1ххх) ? В CS3 есть даже наследование и "полиморфизм" (https://help.codesys.com/api-content...alling-methods).
Изумительный пример и образец. Такой подход , только в жесткой форме hardcoding'ка, использую давно.
Попробовал в теории в режиме симуляции - работает. Очень удобно и, главное, элегантно так получается. А значит правильно работать будет.

[capzap]

Видимо придется смириться. Пока не надоест до конца будут if then писать


Что касается первого, я же написал, что сам код динамического вызова "в процессе машины состояний" не приведен, тут я лишь написал САМ вызов, чтобы показать что не работает как хотелось бы.
...
ко-второму: так именно так и написано, только в начале выполнения (при инициализации) в массив состояний заносятся адреса FB, который потом будут выбираться и вызываться через индексы, то есть
fbInst := arStates[1].iActionHandlerPTR как раз и получает ADR(...)
На этапе программирования мы же не знаем адреса FB, поэтому в начале выполнения заполняем массив состояний адресами вызываемых FB.

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

ПЛК1хх поддерживают только КДС2.3

[dorofeevms]

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

ПЛК1хх поддерживают только КДС2.3

Извиняюсь, capzap, не совсем верно понял первый Ваш вопрос и уточнение, поэтому отреагировал не вполне адекватно.
Как я делаю (или точнее - хочу сделать):
- создаю экземпляр FB (fbSNORMAL: fbNORMAL; fbSSTBY: fbSTBY; ).
- получаю и сохраняю адрес
- в ходе исполнения беру сохраненный адрес и вызываю метод fbInst^.run();
(это то я даже проверил и "оно" работает)

Индекс тоже можно получить на стадии инициализации, куда его только потом запихать не нашел. И этот путь "Закомментировал".
В чистом Си (при программировании для ПЛК или МК) классы (и ООП в целом) не использую, там я вместо FB использую функции void*... (Объявляю прототип, позже объявляю, сохраняю указатель в массиве и т.д.)
Тут с использованием функций в интересующем русле вообще тупик, поэтому и зашел со стороны FB, которые "появляются в памяти" и у которых есть действия.

По поводу ПЛК1хх - промашка моя вышла, Вы правы. Тем более обиднее, и 63й и 73й для задачи подходят.

И, видимо, придется махнуть рукой и делать как делал. Интересно, а вообще либа для CS2.3 существует, которая делает нечто вроде CB_CallFunctionByIndex в либе CAA_Callback.lib?...
За ссылку про программистов НАСА спасибо Понравилось, видел раньше.
Боюсь показаться слишком самоуверенным, но я не очень уважаю программистов НАСА и вообще... пишущих на клавиатурах без ЙЦУКЕН.
Я там был (в том числе, в ЦУП Хьюстон кстати, но не в отделе разработки ПО), и своими глазами Видел, Кто пишет код для НАСА, "нефтянки" и иже с ними

[capzap]

- в ходе исполнения беру сохраненный адрес и вызываю метод fbInst^.run();
(это то я даже проверил и "оно" работает)

вызываете действие, а сами ФБ выполняются или только объявлены

[dorofeevms]

вызываете действие, а сами ФБ выполняются или только объявлены

Вызываются только действия. Я полагаю, что компилятор организует и выделяет память для fb при объявлении, для действий где-то же он место выделяет.
Есть мысли, что если вызвать блок поведение будет другим ? Или сделать что-то вроде "инициализации" блока , вызвав его код (добавить конечно) ?
Можно попробовать вызывать сам FB (типа (fbInst^)() - на что-то страшное похоже ... ). А вообще интересно очень что получится... эх, cs нет на работе....
У меня по ходу обсуждения появилась еще затея ... Ради эксперимента вечером покопаюсь еще.