вопросы, вопросы...

[Филоненко Владислав]

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

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

По 1 КБайту

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

Прерывания скрыты от программиста ПЛК и не нужны ему. Всю необх. информацию (например для реализации режима RTU) можно получить через библиотеку UNM. А скорость приема/передачи при выводе прерываний на пользовательский уровень будет (приблизительно) на 1-1,5 порядка медленнее чем реализация на Си. Вызов прерывания - не простая штука, а правильно писать обработчики - сложно.


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

Путаница с терминологией проистекает из за того, что STRING - на самом деле unsigned char*, но CoDeSys не позволяет работать с типом STRING как с указателем, а использует встроеные функции работы со строками, к-е обрезают строку по нулевому символу. Из-за этого есть небольшие неудобства.
Спасибо за комплимент. Написание документации - на самом деле сложная штука, т.к. один обидится на подробнейшее описание всего, что он знал с пеленок, а другому надо разжевать всё до положения битов в байте.



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


Стараемся, идея со скачиванием интересна, подумаем.

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

Над модернизацией аппаратной платформы идет работа. До завершения анаонсировать ничего не будем.
Идей много, но все эти библиотеки не бесплатны (или требуют лицензионных отчислений). Вы готовы платить цену ПЛК или в неск. раз больше за библиотеку?

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

Именно так, добавил и забыл. Диспетчер задач сам выделит время для выполнения.

6.'VAR' и 'SLOT' - нельзя ли по подробнее? В чём идея введения подобных аттрибутов?
Это часть среды разработки, Slot - зарезарвированное место (одно), Var - от 0 до N мест для добавления модулей. Приает гибкость и позволяет ограничить использование ресурсов.