В процессе изучения мануалов и манускриптов появились некоторые вопросы, а полноценных ответов в форуме пока не нашёл.
Итак.

1.Какой размер буферов приёма и передачи у COM портов?

2.Коммуникации через SysLibCom производятся посредством записи в буфер порта и последующего чтения приёмного буфера?
Существует ли такое понятие, как коммуникационное прерывание? Пример: в порт из сети поступил символ -> генерируется прерывание -> вызывается пользовательская функция, зарегистрированая на обработку этого прерывания. Насколько мне известно, это типовой подход при работе с последовательным портом. Реализован ли он у Вас? Если нет, то по какой причине? Ведь только при таком режиме работы с портом есть возможность обеспечить наилучшую скорость отклика и выполнение практически любых требований реализуемого протокола обмена. Существует ли возможность прямого (низкоуровнего) доступа к порту? Ведь Ваша библиотека UNM в структуре 'RBDATA' выдаёт специфическую информацию (типа времени между байтами), которую через SysLibCom не получить.

3.По библиотеке UNM. В манускрипте, описывающем эту библиотеку, звучат фразы "последовательность байт", "произвольная последовательность байт". Однако, "SetByte" принимает "Line:STRING". В мануале "PLC_Configuration_OWEN.pdf" читаем на странице 8 что у типа данных 'STRING' нижний предел - "Любой символ, кроме 0x00". Вот те раз ! И как быть с нулевым символом? В манускрипте на UNM, при описании этой функции видим:
"Line: STRING - строка содержащая массив байтов для последовательной передачи (до 256 байт);
Len: DWORD - длина массива данных."
Строки, по идее, содержат символы, а не байты. Такая устоялась терминология. Использование вперемешку терминов 'строка' и 'байт' сбивает с толку.
И в самом наборе параметров функции не всё понятно. Зачем нужно поле 'Len'? Если 'Line' - это STRING, то 'Len' сообщает функции, сколько символов из строки нужно передать? Отсчёт, очевидно, с первого символа.
Если 'Line' - это массив байтов, то 'Len' - это количество элементов массива, которые нужно отправить?
Создаётся впечатление, что манускрипт писал либо "глубокий" программист, для которого всё "само собой разумеется", либо тот, кто не понимал до конца, как функция работает.

Вообще, на счёт документации. Сделали хороший контроллер, а с документированием ещё тяжело. А ведь контроллер - это на ~ 80% программный продукт. И лёгкость и эффективность его использования зависит ТОЛЬКО от качества сопроводительной документации. Обратите внимание на работу Siemens. У них на свои продукты (особенно контроллеры и системы программирования) переведённой на русский язык документации больше, чем у всех российских фирм, работающих в
этой области, ВМЕСТЕ ВЗЯТЫХ! За исключением Вашей фирмы, разве что... Но, если не будет прогрессировать качество документации,не избавиться Вам от мегатонны обыденных вопросов на этом форуме никогда... И побольше бы примеров кода (прямо в документации).
Кстати, о форуме... У Siemens на форуме была возможность скачать архив форума в 'chm' формате. Очень удобно. Стянул несколько файлов и в offline спокойно изучаешь. И Вам меньше нагрузка на сервер, и для нас меньше зависимость от доступа к интернету (командировки и всё такое...).

4.В мануале на CoDeSys приводится описание конфигурирование модулей Profibus, CANOpen, DeviceNet. Что это за модули? Это аппаратные сущности или программные? Если аппаратные, то есть ли у Вас планы реализации? Profibus DP сидит на RS-485, для его реализации, по идее, нужна только библиотека. То есть, это возможно без модификации аппаратной платформы.

5.Как работают Ваши коммуникационные модули? Добавляем их в 'PLC Configuration', конфигурируем и больше ничего. Можно пользоваться сконфигурированными переменными. А когда модуль вызывается (получает процессорное время для выполнения своих обязанностей)?

6.'VAR' и 'SLOT' - нельзя ли по подробнее? В чём идея введения подобных аттрибутов?