Чтение данных по Modbus TCP

[Andrey 2014]

Здравствуйте. Пытаюсь читать данные по Modbus TCP из контроллера. Более 120 регистров за раз не читает (приходят нули в ответе). То есть выходит, чтобы мне прочитать все Holding регистры (40000 - 49999). Нужно 166 запросов к контроллеру сделать - это 3 секунды, как то не комильфо. Это я читал в документации что-то не так на протокол или действительно ограничение стоит?
И еще вопрос есть: первые два байта в сообщении - это идентификатор транзакции, написано, что можно произвольно выбрать. Что будет, если я произвольно выберу и случайно окажется еще кто-то, пытающийся читать данные с таким же идентификатором?

[Ryzhij]

А зачем читать все подряд?

[Andrey 2014]

Ну, если читать тут чуть-чуть, там чуть-чуть, то количество запросов будет большим, поэтому я подумал, что проще считать все регистры за раз и выбирать те, что мне надо из массива. А они читаться не хотят :)

[checker]

Все просто. В ответе Modbus под количество байт данных отведен 1 байт. Т.е. устройство в ответ может за раз передать не более 256 байт данных. С учетом размера регистра получается: COIL/DISCRETE INPUT (1 бит) - не более 250 * 8 = 2000 регистров за запрос, INPUT/HOLDING (2 байта) - не более 250 / 2 = 125 регистров за запрос.

По номеру транзакции. Соединение TCP/IP - это соединение типа точка-точка. Ваше соединение другие клиенты не видят, и вы не видите другие соединения. Ваши номера транзакции никак не пересекается с номерами транзакции других клиентов и беспокоиться об этом не надо. Так что ставьте номер какой хотите. Обычно номер транзакции просто увеличивают на 1 с каждым запросом для контроля того, что устройство ответило на тот запрос, который вы сейчас ожидаете.

[Andrey 2014]

checker, спасибо большое, все просто и доступно объяснили!
Но тогда все же остается вопрос. Как же драйвера SCADA системы успевают считывать большие объемы данных по Modbus TCP?

[Ryzhij]

Я никак не пойму, почему у Вас на запросы выходит аж три секунды? Это же не Serial RTU, а Ethernet.
Как Вы насчитали три секунды?

[Andrey 2014]

Я их в цикле опрашиваю последовательно. Возможно поэтому. Попробую асинхронно.

[checker]

Сделал тест у себя. Чтение 9999 HOLDING регистров - это 80 запросов по 125 регистров. Мастер и слейв на одной машине - затраченное время 16 мс. Мастер и слейв на разных машинах в локальной сети - 35 мс.

PS. Для чистоты эксперимента: Windows 10 x64, i7 3.4 ГГц, память 32 Гб, сеть 100 Мбит/сек

[Andrey 2014]

Сделал тест у себя. Чтение 9999 HOLDING регистров - это 80 запросов по 125 регистров. Мастер и слейв на одной машине - затраченное время 16 мс. Мастер и слейв на разных машинах в локальной сети - 35 мс.

это синхронно или асинхронно?

[checker]

Синхронно. В цикле 80 раз подряд: записали запрос, ждем заголовок, читаем заголовок, ждем данные, читаем данные, разбираем ответ, перекладываем регистры из ответа в свой буфер, следующий диапазон.

[Andrey 2014]

Понятно. Буду говнокод перебирать, спасибо!

[Andrey 2014]

checker, а чем вы читали данные? Просто я по локальной сети с контроллера SCADAPack 330 Holding регистры быстрее, чем за 1,5 секунды не могу прочитать при всем желании.

[jov]

Время ответа и впрямь из ряда вон. Самое медленное, что я видел - это ответ от BN 3500/92, порядка 20 мс на 100 регистров. Прежде чем пенять на контроллер, попробуйте посмотреть на трафик любым сетевым снифером - может "бутылочное горлышко" не в нём, а в клиенте

[leon78]

Обычно ПЛК отвечает в конце цикла сканирования. И количество запросов за скан контроллера ограничено.

[Ryzhij]

Обычно ПЛК отвечает в конце цикла сканирования.

Это зависит от наличия коммуникационного сопроцессора и, разумеется, от самой операционки на борту ПЛК.
Кстати, коммуникационные возможности являются одним из отличий PAC от PLC.

[checker]

checker, а чем вы читали данные? Просто я по локальной сети с контроллера SCADAPack 330 Holding регистры быстрее, чем за 1,5 секунды не могу прочитать при всем желании.

Это скорость работы драйвера в нашей SCADA системе Каскад-САУ 4.0. В качестве сервера выступал сервер Modbus TCP из состава той же Каскад-САУ 4.0. Если модератор не сочтет за рекламу, то могу дать прямую ссылку на скачивание, чтобы попробовать. Или можете найти сами в файловом архиве на сайте из моих контактных данных.

Думаю, не совсем корректно мерить контроллер SCADAPack 330 32 МГц c обычным компьютером. А вот с другими контроллерами можно. Сделал сейчас еще тест: взял наш контроллер BCE-5 180 МГц, работает под управлением рантайма от Каскад-САУ 4.0. С него чтение 1000 HOLDING регистров занимает те же 30 мс.

[Andrey 2014]

ответ от BN 3500/92, порядка 20 мс на 100 регистров

ну, я то читаю 10000 регистров, то есть на 100 если умножить, примерно 2 секунды выходит будет читать с этого контроллера.

Сделал сейчас еще тест: взял наш контроллер BCE-5 180 МГц. С него чтение 1000 HOLDING регистров занимает те же 30 мс.

1000 регистров читает примерно за 120-150 мс, но у вас процессор в 5,5 раз быстрее. Или это не влияет?

[checker]

1000 регистров читает примерно за 120-150 мс, но у вас процессор в 5,5 раз быстрее. Или это не влияет?

Конечно, влияет. У нас рантайм на контроллере работает под управлением ОСРВ eCos и параллельно в несколько потоков опрашивает устройства ввода, исполняет программы пользователя, отправляет свои данные на другие узлы по внутреннему протоколу, отвечает на запросы Modbus TCP и т.д. А процессор на все один, и если бы он был не 180 МГц, а 32 МГц, то на Modbus TCP оставалось меньше времени, а, следовательно, контроллер бы банально подтормаживал с ответами, увеличивая суммарное время опроса

[Jackson]

А зачем читать все подряд?

Ну, если читать тут чуть-чуть, там чуть-чуть, то количество запросов будет большим

А нельзя так переконфигурировать адресное пространство, чтобы нужные для опроса данные сложить в соседние регистры? Мы так делаем, это существенно ускоряет обмен особенно на медленных интерфейсах.
Зависит от устройств, понимаю. Может стОит посмотреть на них внимательнее: можно ли так сделать?

[Andrey 2014]

Конечно, влияет.

То есть, в принципе, нормально, что скорость опроса такая низкая на scadapack?

А нельзя так переконфигурировать адресное пространство, чтобы нужные для опроса данные сложить в соседние регистры?

Можно конечно, но я то пишу библиотеку на шарпе для того, чтобы таскать данные из контроллера. Чтобы взял любой контроллер (даже запрограммированный неизвестными мне людьми) и прочитал данные по карте сигналов. То есть частный случай - это когда все хорошо и регистры последовательно занимают адреса, но ведь есть люди, которые любят разбросать данные, как носки по всей квартире, вот для таких случаев я и думал, что будет проще прочитать все регистры, а потом нужные уже вытащить.

[checker]

То есть, в принципе, нормально, что скорость опроса такая низкая на scadapack?

Это вопрос к разработчикам SCADAPack. Если и них главное - опрос блоков ввода-вывода и алгоритмы, а Modbus TCP идет в нагрузку с низким приоритетом по остаточному принципу - тогда это нормально. А может у них сам сервер Modbus TCP плохо написан - тогда не нормально.

[Andrey 2014]

checker, а если я вам дам скомпилированную программку, можете проверить с какой скоростью будет читаться на вашем контроллере? Если боитесь вирусов, то просто исходник могу дать, компилировать в Visual Studio 2015.

[checker]

Давайте программку, адрес написал в ЛС.

[checker]

Поправка к тесту контроллера BCE-5 выше: опрос 10000 HOLDING регистров за 80 запросов занимает 170 мс.