Могу теперь понять, почему известные западные изготовители ПЛК делают такое ограниченное ПО для своих классических моделей. Если поддержано МЭК программирование, то операций с файлами просто нет (не говоря уже о сокетах и тем более указателях) и до свидания! Выбрасывают все, что может вызывать сложности у массового пользователя, оставляют базовое ядро самых ходовых команд. Шаг влево, шаг вправо – нельзя, покупай для этого устройство другого класса. Контроллеры применяются только в своей узкой нише. Их программирование получается очень простым и надежным. Естественно никаких Кулибинских трюков на таких ПЛК делать нельзя. Они намеренно запрещены. Купил вилку для рыбы на пару – используй ее для рыбы и не спрашивай, почему ею не удобно открывать пиво.

Овен зачем-то старается идти на встречу всем пользователям, включая очень продвинутых. В результате, последние имеют возможность творить чудеса с ПЛК. Вплоть до того, что пишут свои языки и интерпретаторы для систем управления перемещениями, делая на ПЛК автоматы и роботы, обычно требующие стоики ЧПУ (в 20 раз дороже и вообще из другого мира).
Системные библиотеки (SysLib…) это типовой функционал компьютеров втянутый в ПЛК. Он вообще очень криво лезет в модель классического сканирующего ПЛК. Например, описанная выше проблема открытия файлов, портов. Тут есть 2 варианта: 1) Синхронные функции. Функция не отдает управление пока не отработает (например, не задвинет всю строку в буфер передатчика). Так делают в компьютерах. Это чревато тем, что можно прозевать другие события, часто гораздо более важные в задачах управления реального времени. Придется однозначно делать проект многозадачным, брать толстые учебники и разбираться с синхронизацией потоков, семафорами и др. и пр. 2) Асинхронные функции. Они возвращают управление сразу. Пользовательская программа пошла работать дальше, а функция в фоне еще завершает свою работу. Тут конечно тоже нельзя совсем тупо программировать. Открытие потоков и их обслуживание надо аккуратно размазать по управляющим циклам. В принципе это не столь сложно. Один раз сделать, чтобы заработало и все.
Технически у Овен все сделано очень разумно. Другой вопрос в том, что это нестандартные штуки, сложных вопросов тут много, мирового опыта их описывать всем понятным языком просто не существует. ИМХО выбросить бы все упоминания про системные биб-ки из документации и давать их только по запросу. Сразу бы вопросов на этом форуме стало раз в 10 меньше.

Со стороны CoDeSys: тема старая, больная. 'Глюки' эти, точнее разночтения вылезают у всех изготовителей ПЛК. Причем у многих, гораздо хуже. Изначально системные библиотеки сделаны как некие шаблоны, которые по мере возможности желательно соблюдать, если это не усложняет их разработку. Не более того. Разные ОС, разные процессоры тянут специфику. Системные биб-ки аппаратно зависимы и имеют полное право отличаться! Поэтому их и не вносят в стандартные. Мало того, в системе хелпа CoDeSys даже предусмотрена возможность отключать описания определенных библиотек и заменять их на свои, при выборе другой модели ПЛК! Поэтому при наличии фирменного описания системной биб-ки не в коем случае не надо читать ее описание от 3S или другого изготовителя ПЛК. Эти описания близко не претендуют на роль более стандартных или более правильных.
Что делается для исправления ситуации? Есть организация такая CoDeSys Automation Alliance, объединяющая изготовителей контроллеров. Ее силами идет разработка библиотек CAA, которые должны сменить системные. Их нужно тщательно проработать, дабы сделать их можно было для любых типов процессоров и ОС существующих в мире. Это не очень просто. Кроме того, выполняется работа по разработке специальных тестов для проверки совместимости. О сроках пока говорить рано.