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

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

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

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

3.По библиотеке UNM. В манускрипте, описывающем эту библиотеку, звучат фразы "последовательность байт", "произвольная последовательность байт". Однако, "SetByte" принимает "Line:STRING". В мануале "PLC_Configuration_OWEN.pdf" читаем на странице 8 что у типа данных 'STRING' нижний предел - "Любой символ, кроме 0x00". Вот те раз :eek: ! И как быть с нулевым символом? В манускрипте на 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' - нельзя ли по подробнее? В чём идея введения подобных аттрибутов?

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

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". Вот те раз :eek: ! И как быть с нулевым символом? В манускрипте на 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 мест для добавления модулей. Приает гибкость и позволяет ограничить использование ресурсов.

<Путаница с терминологией проистекает из- за того, что STRING - на самом деле unsigned char*, но CoDeSys не позволяет работать с типом STRING как с указателем, а использует встроенные функции работы со строками, к-е обрезают строку по нулевому символу. Из-за этого есть небольшие неудобства.>
Тип 'unsigned char*' в мануале на CoDeSys не описан. Есть 'BYTE' и 'USINT'. Вы, видимо, библиотеки пишите на Си и документируете в этом ключе. И получается мешанина.
И, всё-таки, ситуация с нулевым символом не прояснилась. Позволяет ли потенциально чудесная библиотека 'UNM' посылать в сеть нулевые символы? Строка "$00$00$00" (три нулевых символа подряд) пройдёт в порт? И зачем нужен 'Len'?

<Спасибо за комплимент. Написание документации - на самом деле сложная штука, т.к. один обидится на подробнейшее описание всего, что он знал с пеленок, а другому надо разжевать всё до положения битов в байте.>
Сравните обиду нескольких особо одарённых и тяжесть, а порой и невозможность для многих сотен нормальных найти нужную информацию по конкретным вопросам. Ваша цель ведь большие обьёмы продаж, а не удовлетворение самолюбия одиночек? Опять ссылка на Siemens - если Вы изучали их документацию, то обратили, наверное, внимание, что всё написаное ориентировано на людей невысокой подготовки. А обьём излагаемой информации весьма велик. По документации Siemens можно вообще учиться программировать контроллеры с нуля. А у Вас даже не оформлено описание памяти, принципов формирования адресного пространства в отдельный параграф. А ведь положение битов в байте имеет ещё какое значение! И положение байтов в многобайтовых типах! Какой байт лежит в памяти первым? Старший или младший? Мне нужно работать с участком памяти контроллера обращаясь к битам, затем считать этот участок двойными словами, передать их по сети, положить в память и опять считывать отдельными битами. Причём, на контроллере я адресую биты как часть байта (BYTE.BIT), а на удалённой машине - как часть двойного слова (DWORD.BIT). Чтобы выполнить такую работу без ошибок, я должен чётко представлять себе положение битов в байте и байтов в DWORD на обеих платформах. У Вас RISC процессор. Я ничего не знаю о нем и о Вашей платформе. И нужную мне для работы информацию рассчитываю найти в документации.
IMHO - в документации НЕ ДОЛЖНО БЫТЬ такого понятия, как "само собой разумеется".

1) Да позволяет.
Примерно так
Pb:POINTER TO BYTE;
MyStr:STRING(10);
---------------------
PB:=ADR(MyStr);
Pb^:=0;PB:=PB+1;
Pb^:=0;PB:=PB+1;
Pb^:=0;PB:=PB+1;
----
Посылаем строку

спасибо, олег. подобный пример я уже видел, так и собирался делать. хочется, всё-таки, добиться непротиворечивого понимания работы этой функции. интересно, зачем разработчикам понадобилось выбирать в качестве аргумента строку? ведь байтовый массив универсальнее.

1. Len - как раз чтобы можно было передавать в функцию размер, а не ориентироваться на нулевой символ.
2. Нулевые символы передавать можно.
3. Со стрингом - можно сказать так исторически сложилось.

По документации - мы осознаём, что она далеко не совершенна и стараемся её улучшить. У Siemens наверное только штат технических писателей и редакторов больше всего нашего штата с диллерами впридачу...И времени не впример больше было.
А по поводу процессора - ARM AT91RM9200 - эта информация есть в документации и рекл. буклетах. Используется режим LITTLE ENDIAN.

Уважаемый Владислав.
Не воспринимайте мои слова, пожалуйста, как какие-то злые упрёки.:o К Вашей фирме у меня отношение самое позитивное. Помню, как ещё в 2003 году двумя приборами ТРМ-138 в течение двух дней была решена проблема многоточечного учёта температур по турбогенератору, достававшая нас до этого два года. Доступная цена и достаточные возможности – что ещё нужно службе эксплуатации… А теперь у Вас появились ПЛК. И это здорово, ведь бывают у технологических объектов такие сложные с точки зрения регулирования параметры, где обычными ПИД-регуляторами не обойдешься. Нужен ПЛК. Доступный по цене и достаточный по возможностям. Кроме того, сейчас рассматриваем вопрос использования Ваших контроллеров в качестве протокольных шлюзов. Сейчас ведь многие производители цепляют на свои устройства последовательные порты. И обязательно – протокол своей собственной разработки. Представьте себе пять опрашиваемых приборов, и у каждого – свой протокол. Выкручивайся как хочешь…
Что касается документации. Слышал такую формулировку, что разработчик в принципе не способен смотреть на свои творения с нужной для написания документации стороны. По моему, близко к жизни. По себе сужу. И здесь Вам на помощь приходит ФОРУМ! Какие вопросы в документации нуждаются в усовершенствовании, те здесь и всплывают. И я, например, если пишу, что что-то не так, то понимаю это не как претензию, а как осуществление обратной связи между разработчиками и потребителем. Если бы мне было безразлично, какое будущее у Ваших контроллеров, я не тратил бы своё время на эти посты.
Теперь по библиотекам.
UNM. А как Вам такой вариант: вместо функции ‘SetByte’ реализовать две функции – ‘SetBytes’ и ‘SetString’? Первая принимает байтовый массив, а вторая – строку. Никакой неоднозначности. Мне кажется, так было бы лучше. И ещё. Спасибо за ‘RBDATA’, вернее, за служебный байт. Раз уж нельзя получить доступ к порту напрямую, то хоть такая конфетка.
SysLibSockets. Для библиотеки ‘SysLibCom’ Вы написали свой небольшой манускрипт с описанием. А для ‘SysLibSockets’ есть? Ведь в описании от ‘3S-Software’ описания минимум, и везде написано: “ Детальное описание функции … дано в справочной системе соответствующей ОС. ”. А у Вас такого описания нет. Как быть?:confused:

Библиотеку UNM.lib мы менять не будем, т.к. она фигурирует во многих проектах и это вызовет проблемы с совместимостью. SetString вообще лишняя функция. Зачем? 1 преобразование к указателю всегда можно скрыть в доп. функции.


При написании SysLibSockets мы ориентировались на материалы MSDN. Хотя есть особенности, связанные с реализацией функции Listen - на каждую связь Вы должны самостоятельно выделить сокет, а не выделить 1 сокет и получать этой функцией другие сокеты, по мере поступления запросов на связь. Всё таки ресурсы ПЛК ограничены...

Короче, господа покупатели. Берете контроллер, на месяц запираетесь в кабинете и, методом многократных экспериментов, создаёте свою собственную документацию...:(
Не забудьте запастись MSDN, докой по 'AT91RM9200' и терпением...
А основная работа подождёт. И проектировщикам тоже привет.:p Познакомившись с документацией на ПЛК, не думайте, что можете сделать объективный выбор... Сначала нужно на месяц запереться в кабинете...