Modbus на Pascal

А теперь куча вопросов.

1. Как определить, в каком режиме пришел запрос? Если первый байт сообщения 3Ah - это ASCII, иначе RTU? А если передает устройство с адресом 3Ah в режиме RTU?
2. Что такое "интервал тишины, равный времени передачи 3.5 символов при данной скорости передачи в сети"?
3. Устройство имеет 24 входа UNIO. Можно ли считать их дискретными входами, которые можно считать "ссылка 1Х" в функции 02?
4. Что такое входные регистры (ссылка 3Х)?
5. Что такое статусные выходы для CPU188 (функция 07)?
6. Что такое байты событий (функция 12)?
7. Что такое режим "Listen Only" (см. диагностическую подфункцию 4)? Это просто когда ответы не возвращаются что ли ни на какие запросы?
8. Что возвращает функция 17 для CPU188?
9. Что такое регистры файла расширенной памяти (функции 20, 21)?
10.  В описании функции 22 сказано: "Функция поддерживается только 984-785 контроллерами". Поддерживается ли она для CPU188?
11. Что такое очередь (функция 24)?
12. Как организуется регистр диагностики для CPU188?
13. Диагностическая подфункция 10 - что должна очищать?
14. Диагностические подфункции 19 и 20 - как реализуется для CPU188?
15. Диагностическая подфункция 21 - что возвращает?

Понимаю, что мало чего пока понимаю в данном протоколе, поэтому прошу громко не смеяться в случае чего. :)

Остальные вопросы с 5 по 15 - это из разряда "оно надо?". :) Вряд ли понадобится, только если прибор серьезный разрабатывается.

...в сеть с другими режимом передачи. Поэтому вопрос остается в силе.

Ваше право. В принципе можно как вы задумали изначально с автоопределением первого символа. Но адрес 3а в рту теряется.

По ней это время и расчитывается? Если да, то что есть "счетчик символов"?

Счетчик символов, очевидно, и есть те самые 3,5 байта. :)

Т.е. вы хотите сказать, что регистры, доступные только для чтения, следует делать как 3х? Например регистры, хранящие результаты некоторых измерений.

Ага. Переменные которые можно и прочитать и записать извне - в 4х.

По поводу подсчета LRC для ASCII-сообщения.

Что cуммировать, сами байты после их преобразования из НЕХ или их HEX коды? Например, при проверке запроса на Slave с адресом 5 с функцией 03, Суммировать байты 5+3+..... ИЛИ 30Н+35Н+30Н+33Н+....

Создал несколько регистров на OPC-сервере, потом обращаюсь к устройству. Получаю следующий запрос (запрос на чтение регистра 1104 с устройства 1 функцией 3):

3A 30 31 30 33 30 34 35 30 30 30 30 31 41 37 0D 0A

Судя по всему, 41 37 - это LRC.Ее значение A7h = 167.

Читаю описание протокола.

"Алгоритм генерации LRC:
1. Сложить все байты сообщения, исключая стартовый символ ':' и конечные CRLF, складывая их так, чтобы перенос отбрасывался.
2. Отнять получившееся значение от числа FF(Hex) - это является первым дополнением.
3. Прибавить к получившемуся значению 1 - это второе дополнение."

Исключить видимо следует еще и 2 символа, описывающие собственно LRC. Т.е. пропустить 1 байт в начале и 4 байта в конце. Делаю для вышеупомянутого запроса соответствующие действия (len-длина сообщения - в данном случае 17 байт, lrc имеет тип byte):

 lrc:=0;
 for n:=1 to len-5 do
  lrc:=lrc+buffer[n];
 lrc:=$ff-lrc; {первое дополнение}
 inc(lrc);       {второе дополнение}

Получаю B2h = 178

В чем ошибка?