Не стандартный MODBUS

[Rik]

Прошу помощи - консультации специалистов АСУ.
Наша организация смонтировало и наладило оборудование изготовленного в Великобритании, с возможностью подключения системы SCADA. Но специалисты из Китая, которые занимаются наладкой системы SCADA, не смогли сконфигурировать связь. Привожу их доводы, где они предполагают об использовании устройством не стандартного протокола MODBUS (В заводской документации прописывается используемый протокол MODBUS RTU):

Non-standard Modbus message issues of the CPS
During commissioning, the SCADAVantage showed CRC error and we snapped the Modbus message via communication analysis. Compared the standard Modbus (Modicon, SCADAVantage built-in) with the response message from CPS, there is a non-standard response from the CPS that result to the CRC error in the SCADAVantage. The standard and non-standard messages are listed: Standard Modicon Modbus in SCADA: Master query: 01 03 00 65 00 0D 94 10 (HEX)
Correct response: 01 03 18 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx XX XX (xx -data byte total 26 bytes; XX XX are CRC message) (HEX)
Non-standard message from CPS: 01 03 0D xx xx xx xx xx xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx xx xx XX XX (xx -data byte total 26 bytes; XX XX
are CRC message) (HEX)
The data length should be the length of bytes while not words in the standard but
from CPS, it gives the length of words.
In the SCADAVantage, it will only read 13 bytes and 2 bytes after the 13 bytes in
the message will be read as CRC which in fact is not the CRC bytes, the CRC
error happens.

Правы ли китайские специалисты или они ошибаются?

[Василий Иванович]

Правы. В ответе длина должна быть в байтах. Вот выдержка из официальной спецификации:

6.3 03 (0x03) Read Holding Registers
This function code is used to read the contents of a contiguous block of holding registers in a remote device. The Request PDU specifies the starting register address and the number of registers. In the PDU Registers are addressed starting at zero. Therefore registers numbered 1-16 are addressed as 0-15.
The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits.

Request
Function code 1 Byte 0x03
Starting Address 2 Bytes 0x0000 to 0xFFFF
Quantity of Registers 2 Bytes 1 to 125 (0x7D)

Response
Function code 1 Byte 0x03
Byte count 1 Byte 2 x N*
Register value N* x 2 Bytes

*N = Quantity of Registers

[Rik]

Спасибо за ответ. Но еще вопрос на самом ли деле есть не стандартный протокол MODBUS и почему специалисты наладчики в предоставленной им в заводской документации MODBUS RTU Communications Revisions не смогли найти об этом информацию.

[Ryzhij]

Что-то тут не вяжется, однако...
В запросе заявка на чтение 13(dec) / 0D(hex) регистров.
Если регистры стандартные 16 -битные, то в ожидаемом правильном ответе должна быть длина 26(dec) / 1A(hex) байт.
В тексте письма упоминается число 26, но в ждут, и считают правильным, почему-то 18(hex) / 24(dec) байт.
Опечатка?

В реальном ответе приходит 13(dec) / 0D(hex) байт.
Похоже, что регистры 8-разрядные, что ли...

[Rik]

Стал перечитывать заводской документ и нашел такие строки:

Register Map
The register numbers on the Register Map have been reviewed. Holding Registers, or read-write registers, are defined between 0 (0x0000) and 99 (0x0063). Input Registers, or read-only registers, are defined from 100 (0x0064) upwards.

В запросе от SCADA запрашиваются регистры - 101-113 - (01 03 00 65 00 0D 94 10)
OutVolts 101 (0x0065) Output voltage, scaled 0-1023. 853 is 50V or 200V, depending on settings
OutAmps 102 (0x0066) Output current, scaled 0-1023. 853 is 100mV on the shunt.
OutRef1 103 (0x0067) Ref1 mv ref, scaled 0-1023. Full scale is 2400mV
OutRef2 104 (0x0068) Ref2 mv ref, scaled 0-1023. Full scale is 2400mV
OutRef3 105 (0x0069) Ref3 mv ref, scaled 0-1023. Full scale is 2400mV
OutRef4 106 (0x006a) Ref4 mv ref, scaled 0-1023. Full scale is 2400mV
OutDrive 107 (0x006b) Output drive, scaled 0-1000. Full scale is 100.0% thyristor drive
ReleaseReg 108 (0x006c) Major release in high byte, minor release in low byte
DcOnHours 109 (0x006d) Actual value of DC On Timer (Hours)
DcOnSecs 110 (0x006e) Actual Value of DC On Timer (Secs), max 3599
DcOffHours 111 (0x006f) Actual value of DC Off Timer (Hours)
DcOffSecs 112 (0x0070) Actual Value of DC Off Timer (Secs), max 3599
Alarms 113 (0x0071) Bitwise OR of the following:
0x0001 High Voltage Alarm
0x0002 Low Voltage Alarm
0x0004 High Current Alarm
0x0008 Low Current Alarm
0x0010 High Reference Alarm
0x0020 Low Reference Alarm
0x1000 AC Fail
0x2000 DC Fail

может необходимо ставить функцию 04?

[Ryzhij]

Спасибо за ответ. Но еще вопрос на самом ли деле есть не стандартный протокол MODBUS

На самом деле именно стандартный протокол МодБас, полностью отвечающий спецификации, является редкостью.

... и почему специалисты наладчики в предоставленной им в заводской документации MODBUS RTU Communications Revisions не смогли найти об этом информацию.

Надеюсь, это вопрос риторический, т.к. его есть смысл задавать господам наладчикам, а не тут на форуме.

[Ryzhij]

Я не пойму, чем получаемый ответ от системы по 3-ей функции не устраивает?
Используйте его.
Да и не похожи Ваши регистры на "Входные", именно "Хранения" они...

[Rik]

Есть вот такая информация:

Таблица 1 Обозначение данных по типам
Обозначение данных по типам

Старшая цифра логического адреса - 3
Начальный логический адрес - 300001
Тип данных - Input Register - 16 битные данные (word, uint), доступ чтение.
Функции ModBus - функция 4 - чтение

[Василий Иванович]

Фишка в том, что если пользоваться стандартом, то не нужно знать заранее размер holding register в байтах (а он может быть в принципе разный), чтобы быть в состоянии опросить. Говорим "а дай-ка мне 13 твоих регистров", а оно нам отвечает "вот вам 26 байт". И тогда мы спокойно принимаем данные и режем их по два байта. А вот если оно отвечает "вот вам 13 регистров", то мы в общем случае не можем знать заранее, сколько байт пришло, и когда кончится пакет с данными.

[Ryzhij]

Есть вот такая информация:

Таблица 1 Обозначение данных по типам
Обозначение данных по типам

Старшая цифра логического адреса - 3
Начальный логический адрес - 300001
Тип данных - Input Register - 16 битные данные (word, uint), доступ чтение.
Функции ModBus - функция 4 - чтение

Если это про интересующие Вас регистры, то можете по-пробовать использовать 4-ю функцию.
Может быть на неё получите ответ с полем данных длиной в 26(dec) / 1A(hex) байт

[Ryzhij]

Фишка в том, что если пользоваться стандартом, то не нужно знать заранее размер holding register в байтах (а он может быть в принципе разный), чтобы быть в состоянии опросить. Говорим "а дай-ка мне 13 твоих регистров", а оно нам отвечает "вот вам 26 байт". И тогда мы спокойно принимаем данные и режем их по два байта. А вот если оно отвечает "вот вам 13 регистров", то мы в общем случае не можем знать заранее, сколько байт пришло, и когда кончится пакет с данными.

М-м-да... а что Вы предлагаете случае с переменным размером регистров, в одном 16, в другом 24, в третьем 8 бит?
Извращенцы не перевелись, знаете ли...
Поэтому карту регистров знать и использовать на все 100% необходимо, а в пакете ответа обязана транслироваться именно длина поля данных в байтах.

[Василий Иванович]

... а что Вы предлагаете случае с переменным размером регистров, в одном 16, в другом 24, в третьем 8 бит?
Извращенцы не перевелись, знаете ли...

Если запрашивается некоторое количество элементов данных, то при этом подразумевается, что они равны по длине. Во всяком случае в спецификации указан определенный размер для каждого типа. Holding register можно сделать другого размера, то не переменной длины. Это будет в корне противоречить спецификации.

[Rik]

Хочется все таки обратить внимание что регистры 101-113 не Holding Registers, а Input Registers согласно заводской документации
Register Map
The register numbers on the Register Map have been reviewed. Holding Registers, or read-write registers, are defined between 0 (0x0000) and 99 (0x0063). Input Registers, or read-only registers, are defined from 100 (0x0064) upwards.

[Ryzhij]

Хочется все таки обратить внимание что регистры 101-113 не Holding Registers, а Input Registers согласно заводской документации
Register Map
The register numbers on the Register Map have been reviewed. Holding Registers, or read-write registers, are defined between 0 (0x0000) and 99 (0x0063). Input Registers, or read-only registers, are defined from 100 (0x0064) upwards.

Видим-видим!
Вот только в 99,9(9)% случаев и те, и другие регистры прекрасно отзываются на обе команды чтения: и на 03, и на 04.
Хотя кошернее было бы запрашивать по 04-й, тут Вы правы.

[Василий Иванович]

Если опросить по FC4, то и там в ответе длина должна быть в байтах. Может быть, конечно, что в этом случае оно отвечает корректно, хотя вряд ли.

[ASUTP_PLC]

Вставлю свои пять копеек. Из своего опыта. Я опрашивал контроллеры меж собой по Модбас, там разницы особой не было, при опросе через функцию 03 и 04, получал те же данные.
Но когда опрашивал европейский УПП по Модбасу, как-то не мог получить актуальные данные. Получал те уставки что вношу при параметрировании.
Когда опросил через 03 функцию все встало на свои места. Так что абсолютно разные смыслы могут быть в этих адресных пространствах.

Во входных регистрах и регистрах данных.

[ASUTP_PLC]

0D 94 10 Входной запрос спрашивает 13 регистров (D hex =>13 dec).

[Ryzhij]

0D 94 10 Входной запрос спрашивает 13 регистров (D hex =>13 dec).

На тех же колёсах по второму кругу?
Да, в запросе 13 регистров, а в ответе - 13 байт данных.
Хотя по стандарту в ответе данных должно быть 26 байт.
Вероятно, регистры однобайтные (8-разрядные).
И что дальше?

[ASUTP_PLC]

Я просто момент не могу понять. В самом первом посту. 01 03 18 .... (и почему он корректен. 18 hex это 24). Написано что это стандартный ответ.

[Ryzhij]

Я просто момент не могу понять. В самом первом посту. 01 03 18 .... (и почему он корректен. 18 hex это 24). Написано что это стандартный ответ.

В своём недоумении Вы не одиноки.
И об этом уже писалось..