Функциональные блоки на языке ST

[Newcomer]

только одномерные

Это хорошо.

[1exan]

Что будет исполнятся быстрее, макрос из Менеджера компонентов OL или FB на ST, выполняющий аналогичные действия ?

Тут дело не в скорости, а скорее в размере конечной программы.
Мне видится так:
Макрос - это код, который скопируется в тексте программы столько раз, сколько макросов было вставлено в программе. А ФБ на ST имеет одну реализацию, которая вызывается в программе с различными данными (блоками данных каждого из экземпляров)

[Yakut]

Вот так, выложишь что-то, для таких же не особо далёких как и сам (я про себя), чтобы упростить жизнь всем, и узнаешь кучу нового, в том числе и о себе. Будем внимательней и прочитаем стандарт IEC 61131-3, где про фронт и срез говорится следующим маслом - R_TRIG - Rising Edge Detector, F_TRIG - Falling Edge Detector. Обратимся к официальной справке Овен Лоджик, там сказано следующее - Детектор переднего фронта импульса (RTRIG). Обратимся к CodeSys2.3 - Функциональный блок R_TRIG генерирует импульс по переднему фронту входного сигнала. Ну и CodeSys 3.5 - Функциональный блок для выявления переднего фронта.
Вынужден учиться на том, что дают.

R = rising восхождение
F = falling падение.

[Danila Kholkin]

Не знаю, было такое раньше, но сейчас функции и ФБ на SТ размещаются в папке Другие. А в какую-нибудь свою папку их можно записать?
Лоджик 2.5
И, еще, если сделать описание макроса на FBD, то оно отображается в библиотеке. Почему бы такое не сделать для ST?

В справке OL написано как это сделать , там надо специальных тегах прописывать. Вообще с документированностью все плохо из разных мест по чайной ложке. про массивы можно только из форума прочитать в справке про масивы нет . Я так и не понял зачем нужны функции на ST если функциональный блок делает тоже самое и дает больше возможностей

[1exan]

В справке OL написано как это сделать , там надо специальных тегах прописывать. Вообще с документированностью все плохо из разных мест по чайной ложке. про массивы можно только из форума прочитать в справке про масивы нет . Я так и не понял зачем нужны функции на ST если функциональный блок делает тоже самое и дает больше возможностей

А зачем легковые авто, если есть автобусы?

[yura2507]

В справке OL написано как это сделать , там надо специальных тегах прописывать. Вообще с документированностью все плохо из разных мест по чайной ложке. про массивы можно только из форума прочитать в справке про масивы нет . Я так и не понял зачем нужны функции на ST если функциональный блок делает тоже самое и дает больше возможностей

Функция, помимо отличающегося от ФБ вызова, ещё и экономит ресурсы ПР. Если не требуется сохранять состояние какой-то "внутренней" переменной - всегда предпочтительнее использовать функцию.

[Cs-Cs]

Функцию удобно использовать тогда, когда нужны только расчёты илии обработка данных по одному общему алгоритму. Например:
* Что-то поделить на коэффициент, умножить на переданное значение импульсов и получить расход в литрах;
* Проверить, попадает ли время часов в заданный интервал.
* Обработать какие-нить данные с датчика по алгоритму "Если это не равно 0xFFFF, то подели на 100 и получишь температуру, а если равно - это ошибочное значение"
* Вычислить минимум или максимум из переданных значений

Функции не сохраняют свои внутренние переменные нигде, а все расчёты ведутся на лету. Суть таких функций - чтобы программу писать более компактно.
А каждый нарисованный на проекте FB сохраняет свои переменные и жрёт память.

[Ollema]

у кого то был случай нехватки памяти? просто вопрос ради интереса, так то я весьма рад ФБ на ST: писал макрос, куча входов-выходов, логика внутри, задолбался эту паутину строить и печалиться если ее переделывать приходилось. Плюнул и быстренько написал всю логику на ST. Красиво, компактно, понятно. Супер!

[Cs-Cs]

Ollema У меня только Retain кончаются, потому что я навыдумывал хранить всякую статистику типа Min-Mix за месяц и год, дата последнй аварии и так далее.
В ПЛК я давно на ST перешёл - это удобнее.

[fatlortroll]

Развитие ST в OwenLogic не может не радовать. А на фоне сворачивания CoDeSys 2.3 ПР-ки представляются неплохой альтернативой младшим моделям ПЛК.