Глобальные переменные

Первоначально опубликовано Максим Ананских ...Впрочем, система программирования могла бы включать в себя средства, предотвращающие возможность возникновения конфликтов между задачами. А что сделано в CoDeSys для этого?

Генерируемый компилятором CoDeSys код максимально простой и быстрый. Никаких блокировок и запретов прерываний по умолчанию туда вставлять нельзя, иначе получим такие тормоза, что ОС ляжет. Пока еще вытесняющая многозадачность в ПЛК реализуется редко, только в дорогих с жестким РВ. В массовых ПЛК реализована корпоративная многозадачность. Там нет этих проблем в принципе. Задача всегда дорабатывает цикл, прежде чем отдать управление. Можно делать кучу циклических задач с совершенно безопасным взаимодействием через глобальные. Тип и качество реализации многозадачности в контроллере несложно протестировать. См. тут.

- Доп. вопрос, связанный с многозадачностью, это блокирующие POU. Это не стандартные МЭК POU, а всяческие расширения, более характерные для ПК. Сейчас нет стандарта. В разных ПЛК, в разных ОС есть отличия. Все начинающие пользователи пишут архивы так: открыть файл, дописать в него информацию, закрыть. Запись на флешку может занимать несколько секунд. Вопрос как быть в функции записи? Вернуть управление по окончании работы (блокирующий) = рабочий цикл будет заторможен. Надо бить проект на задачи. Вернуть управление сразу и вести запись в фоне = нельзя так сразу закрывать файл, надо организовывать опрос ожидания конца записи. Короче, для V3 инициативной рабочей группой пользователей разработаны спецификации единых библиотек CAA с не блокирующими вызовами POU. Они гарантировано совместимы в любых системах. ИМХО это очень хороший шаг. Лучше не бороться с эффектами многозадачности, а обеспечить мощные компоненты, которые позволят писать простые и понятные однозадачные программы.

- Еще в V3 реализованы приложения. В одном ПЛК может сидеть несколько виртуальных ПЛК с независимой работой.

- В ПЛК с несколькими процессорами... тут я лучше остановлюсь. Тема связанная с глобальными и многозадачностью, но отдельная

Неожиданные выводы
1) Стандартом МЭК 61131-3 для межзадачного взаимодействия предусмотрены глобальные и прямо-адресуемые переменные. Для классических ПЛК задач этого достаточно. Если вдруг мы на ПЛК наберемся решимости решать компьютерные задачи (базы данных, коммуникационные шлюзы и пр.), то этих средств будет мало.

(На такой случай в CoDeSys предусмотрен ряд расширенных механизмов многозадачности и их взаимодействия. В их числе: вызов задач по событиям, обработка событий и аппаратных прерываний на МЭК языках (только в CoDeSys и ни в какой другой МЭК среде и близко нет), создание и управление задачами, семафоры, разделяемая память, потоки, файлы. Подробнее см. библиотеки: SysLibTasks, SysLibIECTasks, SysLibEvent, SysLibCallback, SysLibFileStream, SysLibInt, SysLibSem, SysLibShm.)

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

3) Ответственность за правильную реализацию и тестирование любого программного проекта ложиться на его авторов. Иначе никак.

   

Первоначально опубликовано Максим Ананских SysLibFileStream и SysLibFileAsync плоховато документированы. Непонятно, как они работают. Ну и, конечно же, они поддерживаются не на всех платформах...

1) Ну, что касается SysLib.. , то тут нельзя вообще говорить о совместимости разных ПЛК. Исторически вопрос стаял так: я изготовитель ПЛК, хочу делать их с CoDeSys, но лучше чем у других, с доп. набором функций, которых нет у других. Могу ли я такие биб-ки добавить в систему? Ответ: Да. Делайте свои особенные биб-ки и называйте их ‘СистемнаяБиблиотекаЧтоХочу’, чтобы всем было понятно что это. Стандартизация это хорошо, но должна же быть возможность выделится и ввести нечто свое уникальное (сверх стандартного).  Вот SysLib.. и есть такая форточка, куда можно высунуться.

Первоначально опубликовано Максим Ананских Об этом хотелось бы услышать подробнее. Правда, я слышал что-то подобное от Владимира Зюбина - случайно, не о Switch-технологии речь?

Да, Владимира Зюбина и я бы послушал с удовольствием на эту тему (и любую другую)

ИМХО:

2) Представьте себе идеальный ПЛК. В нем любая команда выполняется мгновенно. В нем можно писать программы с последовательным кодированием состояний (как в Switch) никаких проблем не будет. Все они проскочат мгновенно и можно не ломать голову. Можно писать все параллельно с совершенно безопасно сделанным (в плане того, что выше обсуждали) планировшиком задач, работающим по циклам (как в языке Рефлекс у Зюбина). Короче, как не строй операции рядами или колоннами все будет всегда хорошо.  В реале нельзя сделать идеальный ПЛК, но можно к этому стремиться. Для этого все функции и функциональные блоки должны быть не блокирующими! Это касается как стандартных блоков, так и тех что мы делаем сами в своей программе.
Это кажется банальным. Однако вызывает матерные вопли почти у всех начинающих ПЛК программистов при обучении. Вы, Максим наверняка с этим сталкивались. Например, надо сделать задержку в программе на 100 мс. На языке Си есть функция derlay(100), она просто тормозит всю работу на это время. Но, о ужас, ничего такого в МЭК нет. Таймеры МЭК не задерживают выполнение, а возвращают управление сразу и надо думать и организовывать контроль выхода этого таймера. Это кажется зверски неудобным. Когда человек начинает писать свои функции, то ему логичнее делать так, чтобы функция закончила работу (например, передачу строки в порт) и затем вернула управление.  Получается блокирующий вызов. Получаются медленные программы. Приходится выносить их в отдельные задачи. Обобщаю: если бы все стандартные POU и самодельные работали почти мгновенно, то при современных быстродействующих процессорах нужда возиться с вытесняющей многозадачностью в ПЛК практически не возникала. Вот собственно и все.

Обобщая 1 и 2:  а) надо не ждать, пока появятся стандарты, но и не плевать уж совсем на совместимость.  Можно объединять усилия и делать совместимость доп. библиотек хотя бы в рамках некой группы изготовителей ПЛК. б) все элементы всех библиотек должны быть не блокирующими.  На практике, из а) и б) в CoDeSys появились CAA библиотеки, которые сейчас отрабатываются дюжиной изготовителей ПЛК и придут на смену SysLib..