Записная книжка разработчика

Мои проекты

Протокол Modbus в устройствах на базе микроконтроллеров. Часть 1.3

| Comments

Продолжение. Начало здесь: http://32bit.me/?p=355 - введение; http://32bit.me/?p=373 - часть 1.0; http://32bit.me/?p=377 - часть 1.1; http://32bit.me/?p=395 - часть 1.2.

Кратко рассмотрим обмен данными между ведущим и ведомым устройством для других типов регистров.

Регистры 0х, чтение

Регистры 0х представляют собой 1-битные регистры с поддержкой как чтения, так и записи. Изначально они предусматривались для управления дискретными выходами (coil, обмотка реле), однако на практике могут использоваться как для входов, так и для выходов.

Разместим на панели, которой мы пользуемся для наших экспериментов, 8 дискретных индикаторов, присвоив им адреса с 1 до 8.

Запрос панели: 01 01 00 00 00 10 3D C6

В этом запросе:

01 - адрес устройства

01 - номер функции

00 00 - начальный адрес

00 10 - количество регистров, подлежащих чтению

3D C6 - контрольная сумма

Здесь видно, что панель опрашивает 1016 = 1610 входов, даже если реально ей нужно опросить только 8. Если входов, которые нужно опросить, больше 16, будут опрашиваться входы, в количестве, кратном 16. Такова особенность реализации данного ведущего устройства.

Ответ ведомого:

01 01 02 01 14 B8 63

01 - адрес устройства

01 - номер функции

02 - количество байт, которые будут переданы

01 14 - байты, соответствующие состоянию дискретных регистров. 0-й бит первого байта соответствует начальному адресу. Таким образом, 01 14 соответствует следующему состоянию входов:

----байт 01 ---  ---------байт 14 -----
0 1 2 3 4 5 6 7   8 9 10 11 12 13 14 15  N входа
1 0 0 0 0 0 0 0   0 0 1  0  1  0  0  0   состояние

Регистры 0х, запись

Запрос панели:

01 05 00 1D FF 00 1C 3C

01 - адрес устройства

05 - функция "Force Single Coil"

00 1D - адрес регистра

FF 00 - это значение используется, если нужно записать в регистр 1, в противном случае в этих байтах должно быть значение 00 00

1С 3С - контрольная сумма

Ответ ведомого совпадает с запросом:

01 05 00 1D FF 00 1C 3C

Регистры 1х, чтение

Чтение из регистров 1х аналогично чтению из регистров 0х, меняется только номер функции с 01 на 02.

01 02 00 00 00 10 79 С6 - запрос ведущего

В этом запросе:

01 - адрес устройства

02 - номер функции

00 00 - начальный адрес

00 10 - количество регистров, подлежащих чтению

79 C6 - контрольная сумма

01 02 02 01 14 B8 27 - ответ ведомого

01 - адрес устройства

02 - номер функции

02 - количество байт, которые будут переданы

01 14 - байты, соответствующие состоянию дискретных регистров. 0-й бит первого байта соответствует начальному адресу. Таким образом, 01 14 соответствует следующему состоянию входов:

----байт 01 ---  ---------байт 14 -----
0 1 2 3 4 5 6 7   8 9 10 11 12 13 14 15  N входа
1 0 0 0 0 0 0 0   0 0 1  0  1  0  0  0   состояние

Запись в регистры 1х не поддерживается.

Регистры 3х чтение

01 04 00 00 00 01 31 CA

Чтение из регистров 3х аналогично чтению из регистров 4х, номер функции меняется на 04.

Запрос ведущего:

01 - адрес ведомого

04 - номер функции

00 00 - начальный адрес

00 01 - количество регистров, подлежащих чтению

31 CA - контрольная сумма

Ответ ведомого:

01 04 02 00 01 78 F0

01 - адрес ведомого

04 - номер функции

02 - количество байт, которые будут переданы

00 01 - состояние регистров, начиная с адреса, указанного в запросе

78 F0 - контрольная сумма

Запись в регистры 3х не поддерживается.

На этом рассмотрение команд протокола Modbus можно считаль законченным.

На примере обмена операторской панели с устройством при чтении регистров 0x мы видели, что панель запрашивает состояние 16 регистров даже если реально требуется прочитать меньшее их количество. Можно привести и другие аналогичные ситуации: так, например, OPC-сервер NAPOPC запрашивает регистры 4х порциями по 16 шт, даже когда нужно прочитать всего один. Вот его запрос (используется рассмотренная выше функция 03):
01 03 00 00 00 10 44 06.
А вот ответ ведомого:
01 03 20 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A 00 0B 00 0C 00 0D 00 0E 00 0F 00 00 EE 96.
Конечно, такой подход крайне неэффективен с точки зрения производительности. Ненужные пересылки загружают сеть, увеличивая время реакции системы.

Продолжение следует

Владимир Татарчевский