Siemens S7-1200, Modbus TCP и "Connection refused"

[shworker]

Приветствую всех.
Столкнулся со странной ситуацией.
Имеем ПЛК Siemens S7-1200, откуда по Modbus TCP вычитывается пара регистров раз в 3 секунды самописным ПО.
Некоторое время все идет хорошо. Данные читаются. Но через 20-30 минут получаем "Connection refused" и невозможность подключится.
При этом ping до ПЛК идет стабильно. Решается проблема перезапуском ПЛК по питанию.
Пробовал и другой софт - в частности modpoll (https://www.modbusdriver.com/modpoll.html). Результат тот же.
Собственно, вопрос - сталкивался ли кто с подобным, и как решали.
PS: Сам я не специалист по Siemens. Специально приглашали специалиста, который произвел первоначальную настройку ПЛК.

[VADR]

Подобное было с ET200SP. Реализация сервера Modbus TCP штатными средствами через MB_SERVER. Проблема была в том, что такой сервер поддерживает не более одного подключения одновременно. Второму отказывает. Вы не пытались одновременно подключиться другим клиентом? Мы (вернее, разработчики системы, которые на том объекте работали) в тот раз вышли из положения созданием отдельных серверов для каждого клиента на разных IP портах.

[Михайло]

Да, внутри S7-1200 не должно быть TCP-соединений с одинаковым Connection_ID. Надо копать проблему в этом направлении.

[shworker]

Итак, новости. Для начала - структура тестового стенда:
ПЛК --> Ethernet --> Роутер с 4G модемом --> VPN --> сервер.
Проведенное более тщательное расследование с использованием tcpdump показало, что закрытие TCP сессии на стороне ПЛК не происходило моментально. В результате - отказ в принятии новых соединений. Причем какой-либо закономерности в величине задержки выявлено не было. Это происходило рандомно. То есть софт на стороне сервера сказал "До свидания", а пакеты о закрытии сессии на роутере видны только спестя некоторое кол-во времени.
Решение - перенос софта, занимающегося опросом ближе к ПЛК - на роутер. Полет нормальный.

[keysansa]

Проблема была в том, что такой сервер поддерживает не более одного подключения одновременно. Второму отказывает.

По спецификации Modbus - сервер только один.
Если два клиента отвечают одновременно - чаще всего косяк в адресах.

[VADR]

С серверами и клиентами всё наоборот. Сервер в modbus tcp - аналог слейва в modbus rtu, клиент - аналог мастера. Мастер, он же клиент, отправляет запрос, слейв, он же сервер, отвечает. Спецификация modbus rtu через rs485 допускает только одного мастера во избежание коллизий, но в modbus tcp через ethernet коллизии устраняются другим путём, ничто не мешает одновременно сосуществовать нескольким клиентам. К приемеру, у moxa в характеристиках устройств прописано максимальное количество одновременных соединений.

[keysansa]

С серверами и клиентами всё наоборот.

По моему, вы с OPC путаете, в Modbus не меняется подчиненность с переходом на протокол. OPC - там да, непривычно для начала.

, но в modbus tcp через ethernet коллизии устраняются другим путём, ничто не мешает одновременно сосуществовать нескольким клиентам.

Ethernet так же не позволяет одновременной передачи данных по линии.

Отправлено спустя 19 минут 29 секунд:

ПЛК --> Ethernet --> Роутер с 4G модемом --> VPN --> сервер.
Проведенное более тщательное расследование с использованием tcpdump показало, что закрытие TCP сессии на стороне ПЛК не происходило моментально. В результате - отказ в принятии новых соединений.

Не понятно, что мешает принять новое соединение TCP службе. Можете дамп предоставить, где были запреты?

[VADR]

По моему, вы с OPC путаете, в Modbus не меняется подчиненность с переходом на протокол. OPC - там да, непривычно для начала.

Мастер обращается к слейвам, слейвы отвечают на запросы и без запросов самостоятельной активности не проявляют.
Клиенты обращаются к серверам, сервера отвечают на запросы и без запросов самостоятельной активности не проявляют.
Никакой смены подчинённости, ни в modbus, ни в opc. С OPC часто бывает путаница по другой причине. OPC сервер является сервером по отношению к OPC клиентам. Но если это, к примеру, OPC сервер для протокола modbus tcp, то в нём есть клиентская часть по отношению к серверу modbus tcp, с которым идёт обмен данными.

Ethernet так же не позволяет одновременной передачи данных по линии.

Одновременной - да, не позволяет. Но имеет собственный механизм разрешения коллизий на 2-м уровне OSI (на первом - неактуально с тех пор, как хабы канули в лету, уступив место свитчам), благодаря чему на 7-м, прикладном, уровне OSI об этом беспокоиться не надо. Клиенты могут выдать в сеть запросы одновременно, а уже сетевое оборудование позаботится о том, чтобы к серверу они пришли по очереди.

[keysansa]

Но если это, к примеру, OPC сервер для протокола modbus tcp, то в нём есть клиентская часть по отношению к серверу modbus tcp, с которым идёт обмен данными.

Нене, я при написании, не касался конкретики (чего там этот OPC сервер опрашивает), только часть DCOM (хотя он тоже умеет в TCPIP). Так вот, в OPC - "клиент" (программа) опрашивает "сервер" (который в свою очередь, например, по Modbus опрашивает устройства).

Одновременной - да, не позволяет. Но имеет собственный механизм разрешения коллизий на 2-м уровне OSI (на первом - неактуально с тех пор, как хабы канули в лету, уступив место свитчам), благодаря чему на 7-м, прикладном, уровне OSI об этом беспокоиться не надо. Клиенты могут выдать в сеть запросы одновременно, а уже сетевое оборудование позаботится о том, чтобы к серверу они пришли по очереди.

Я специально написал про одновременный. Одновременная работа двух устройств, в сети Ethernet так же не возможна, на любом уровне OSI. Коммутаторы разделяют сеть на сегменты.
ЗЫ. И хабы никуда не пропали, используются в высокоскоростных и высокодоступных шинах на базе физики Ethernet.

[VADR]

Так вот, в OPC - "клиент" (программа) опрашивает "сервер" (который в свою очередь, например, по Modbus опрашивает устройства).

Это везде так. Это принцип построения любых клиент-серверных систем: клиент отправляет запрос - сервер на него отвечает.

Одновременная работа двух устройств, в сети Ethernet так же не возможна, на любом уровне OSI. Коммутаторы разделяют сеть на сегменты.

Одновременная - в смысле на одном кабеле? Такое было на коаксиале и в последнее время используется чрезвычайно редко. Также - на хабах (имея в виду ethernet хабы, а не какие-либо другие) устройства вещали в сеть, объединённую на 1-м уровне (т.е. физическом). Чтобы избежать коллизий в этом месте, каждое устройство одновременно отправляло пакет и принимало его из линии (такое возможно только на полудуплексе - на полном дуплексе это невозможно), при этом сравнивая принятое с отправленным. Если есть отличия - значит, кто-то ещё одновременно попытался что-то отправить, пакет испорчен и надо повторить передачу через некоторое время. Алгоритм расчёта смещения по времени для таких ситуаций гарантировал, что разные устройства сместят передачу пакетов на разное время. Иначе они опять столкнутся при передаче (второе устройство тоже заметило коллизию и тоже повторяет отправку).

Коммутаторы разделяют сеть на сегменты.

Правильно. Коммутаторы, являясь устройствами L2, делят сеть на сегменты L1, где каждый сегмент - одиночный линк точка-точка между одним устройством и коммутатором. Там в принципе невозможны коллизии, ибо нет прямого соединения между линиями TX и RX. Там возможен полнодуплексный режим и чаще всего там он есть. Доставкой пакетов к получателям занимается коммутатор на уровне L2, и если он принял какие-то пакеты по каким-то портам одновременно, и эти пакеты адресованы одному получателю,- коммутатор выстраивает их в очередь, т.е. доставляет со смещением по времени. Там ещё можно долго говорить о принципах построения этой очереди. Внимательно изучаем, в частности, стандарт 802.1P.

И хабы никуда не пропали, используются в высокоскоростных и высокодоступных шинах на базе физики Ethernet.

Именно ethernet-хабы? Можно пример?

[keysansa]

Это везде так. Это принцип построения любых клиент-серверных систем: клиент отправляет запрос - сервер на него отвечает.

Точно? Именно клиент отправляет запрос? В Modbus - совсем наоборот. Сервер отправляет запрос, нет? А OPC, чутка в стороне? Я все правильно прочитал?

Одновременная - в смысле на одном кабеле? Такое было на коаксиале и в последнее время используется чрезвычайно редко. Также - на хабах (имея в виду ethernet хабы, а не какие-либо другие) устройства вещали в сеть, объединённую на 1-м уровне (т.е. физическом). Чтобы избежать коллизий в этом месте, каждое устройство одновременно отправляло пакет и принимало его из линии (такое возможно только на полудуплексе - на полном дуплексе это невозможно), при этом сравнивая принятое с отправленным. Если есть отличия - значит, кто-то ещё одновременно попытался что-то отправить, пакет испорчен и надо повторить передачу через некоторое время. Алгоритм расчёта смещения по времени для таких ситуаций гарантировал, что разные устройства сместят передачу пакетов на разное время. Иначе они опять столкнутся при передаче (второе устройство тоже заметило коллизию и тоже повторяет отправку).

Зачем вы выделяете "Одновременная", и опускаете все остальное. Я же два раза написал, ОДНОВРЕМЕННАЯ РАБОТА ДВУХ УСТРОЙСТВ В СЕТИ.
По вашему мнению, сеть из чего состоит, что вы так пишете?
И коаксиал и витая пара, оптика на одномодовом волокне, два модема на полёвке. Все это работает последовательно. Только 2 устройства в одной сети в единицу времени.
На счет полудуплекса и полного дуплекса - вы тоже ошибаетесь с точностью наоборт.
Полный дуплекс, как и следует из его названия, работает и на прием и на передачу одновременно (полудуплекс - это рация, с одной частотой). Но только на ДВУХ устройствах. Все равно, только ДВУХ.
Да, кто в сети начинает вещание, решает алгоритм коллизий. Но это решается на самом низшем уровне OSI 1, физика. Но весь механизм предназначен ТОЛЬКО для того, что бы решить, какие ДВА устройства будут общаться.
Выше по OSI уже коллизии не встречаются, как класс.

ЗЫ. Перечитал, получилось резко, по моему... Прошу прощения.
1. 10 устройств общаются через хаб. Обмен ведут 2 устройства в единицу времени.
2. 10 устройств общаются через свитч. Обмен ведут 10 устройств с 10 портами свича. 2 устройства в единицу времени все равно. Отсюда требования к шине свича, памяти свича, и разница между TCP и UDP (и прочими, например ICMP).

[VADR]

Точно? Именно клиент отправляет запрос? В Modbus - совсем наоборот. Сервер отправляет запрос, нет? А OPC, чутка в стороне? Я все правильно прочитал?

Точно. Везде. Клиент запрашивает - сервер отвечает. И в Modbus тоже. В modbus tcp клиент - аналог мастера в modbus tru и ascii, работающих на rs-485; сервер - аналог слейва.

И коаксиал и витая пара, оптика на одномодовом волокне, два модема на полёвке. Все это работает последовательно. Только 2 устройства в одной сети в единицу времени.

Одновременно - только одно устройство в сегменте сети L1 в полудуплексном режиме, два устройства в полнодуплексном режиме в сегменте L1, в сегменте сети L2 - ограничивается техническими характеристиками коммутаторов. Запросы могут прийти одновременно на все порты коммутатора, далее всё решается реализацией очереди в нём. Адресату (если он один) запросы передаются последовательно из очереди в коммутаторе. То есть тут как бы тоже максимум два одновременных устройства в полнодуплексном режиме: коммутатор и устройство-адресат, но это никак не мешает (возвращаясь к первоначальному вопросу) серверу modbus tcp иметь одновременно несколько установленных tcp-соединений с разными клиентами. Количество определяется характеристиками оборудования и программного обеспечения. Реализация modbus tcp в контроллерах S7-1200/1500 работает только с одним соединением на одном ip порте, второму клиенту отправляет отказ в установлении соединения. Шлюзы modbus rtu/tcp от moxa, если мне память не изменяет, работают с 4 одновременными соединениями, отказывают пятому. К поведению оборудования на L1 это не относится никак.

1. 10 устройств общаются через хаб. Обмен ведут 2 устройства в единицу времени.

Только одно устройство одновременно. Полнодуплексных хабов не бывает и не было в принципе.

2. 10 устройств общаются через свитч. Обмен ведут 10 устройств с 10 портами свича. 2 устройства в единицу времени все равно.

В полнодуплексном режиме - два устройства в сегменте L1, одно из которых - коммутатор. В полудуплексном - одно устройство. Если не ограничиваться L1 - в L2 одновременно могут работать хоть все порты коммутатора.

Отсюда требования к шине свича, памяти свича, и разница между TCP и UDP (и прочими, например ICMP).

При чём тут вообще tcp и udp? Это вообще на L3 и никакого отношения к теме не имеет. TCP требует установления соединения, UDP - нет. То есть - TCP не может работать, если на "другой стороне" никого нет, UDP - пофиг, слушает ли его кто.

[keysansa]

Точно. Везде. Клиент запрашивает - сервер отвечает. И в Modbus тоже. В modbus tcp клиент - аналог мастера в modbus tru и ascii, работающих на rs-485; сервер - аналог слейва.

OPC вы намеренно пропустили или не вспомнили? Я в первом сообщении говорил про то, что именно в OPC меняются местами клиент и сервер.

Одновременно - только одно устройство в сегменте сети L1 в полудуплексном режиме, два устройства в полнодуплексном режиме в сегменте L1, в сегменте сети L2 - ограничивается техническими характеристиками коммутаторов.

Ой... Все ))) С кем ОДНО устройство общается в полудуплексе? ОДНО устройство может только вещать.
Судя по L2 - вы меня не понимаете. Давайте паузу возьмем.

Только одно устройство одновременно. Полнодуплексных хабов не бывает и не было в принципе.

Гм... Разработчики с вами не согласны. Почитайте Powerlink спецификацию, например.

При чём тут вообще tcp и udp? Это вообще на L3 и никакого отношения к теме не имеет. TCP требует установления соединения, UDP - нет. То есть - TCP не может работать, если на "другой стороне" никого нет, UDP - пофиг, слушает ли его кто.

Это порождение свичей. От них идут потери пакетов и все отсюда связанное.
Почитайте спеки.

ЗЫ. Мало запомнить уровни OSI. Надо разбираться в них.

ЗЫЫ. Вы включите голову и подумайте, зачем в сети, состоящей из хабов, разделение на TCP и UDP?

[VADR]

OPC вы намеренно пропустили или не вспомнили? Я в первом сообщении говорил про то, что именно в OPC меняются местами клиент и сервер.

Намеренно пропустил. Он такой же, как и все. Клиент инициирует обмен, сервер отвечает на запросы. И даже когда (если?) будут упомянуты callback'и (это касается только dcom и "классических" opc) - ничего не изменится. В opc клиент останется клиентом, сервер - сервером. С точки зрения tcp - в процессе появится функция tcp сервера у opc клиента, но для opc разницы нет: всё равно все действия сервера - реакция на запрос клиента.

С кем ОДНО устройство общается в полудуплексе? ОДНО устройство может только вещать.

Так на L1 вообще никто ни с кем не общается. Все только вещают. Количество одновременно вещающих зависит от полнодуплексного либо полудуплекского режима. Общение начинается, когда у сообщения есть адресат, а это уже не ниже L2 и тут количество одновременно общающихся обусловлено протоколом:
TCP - два устройства одновременно, между ними устанавливается соединение.
UDP - может быть два (если один адресат), может быть больше для мультикаста.
ICMP - от одного устройства до полного размера сегмента сети (бродкаст)
ARP - вообще любое устройство, имеющее ip адрес, про включении в сеть начинает с бродкаста, то есть сообщения всем.
и, к слову, HTTP: при открытии страницы на этом форуме ваш браузер создаёт одновременно 9 TCP-соединений с разными серверами, и со всеми ними общается. Это если не считать DNS :)

Гм... Разработчики с вами не согласны. Почитайте Powerlink спецификацию, например.

Это который ethernet через сеть ~230В? Там только полудуплекс и иного не может быть в принципе. Если имеется в виду что-то другое - модель устройства в студию.

Это порождение свичей. От них идут потери пакетов и все отсюда связанное.

омайнгот...

ЗЫ. Мало запомнить уровни OSI. Надо разбираться в них.

чего Вам и желаю.

Давайте паузу возьмем.

Да какую паузу? Заканчивать пора.

[yoos86]

IP он и в Африке IP, но вот реализации ТСР на разных ОС могут отличаться. При плохой связи ваша ОС может пытаться восстановить ТСР соединение, а со стороны ПЛК подумать что это совершенно новое подключение, такое иногда бывает когда сервер на чем-то nix'овом а клиент на винде. Следует копать в эту сторону.
ЗЫ: может для языка на котором у вас ПО есть библиотека реализующая S7 протокол ? Тогда стоило бы попробовать перейти на S7 протокол вместо modbus.

[keysansa]

Точно. Везде. Клиент запрашивает - сервер отвечает. И в Modbus тоже. В modbus tcp клиент - аналог мастера в modbus tru и ascii, работающих на rs-485; сервер - аналог слейва.

Прошу прощения, вы правы. Полез за доказательствами на modbus.org, а там в спецификации (https://modbus.org/docs/Modbus_Applicat ... V1_1b3.pdf, Параграф 4,1) реально, клиент инициирует сообщение, вне зависимости от RTU, ASCII или TCP.
Еще раз прошу прощения ) Ушел чёркать документацию от производителей, свои руководства...

Одновременно - только одно устройство в сегменте сети L1 в полудуплексном режиме, два устройства в полнодуплексном режиме в сегменте L1, в сегменте сети L2 - ограничивается техническими характеристиками коммутаторов. Запросы могут прийти одновременно на все порты коммутатора, далее всё решается реализацией очереди в нём.

Так на L1 вообще никто ни с кем не общается. ... Общение начинается, когда у сообщения есть адресат,

Ваше определение тоже не подходит. Адресат есть, но не доступен - это не общение.

Как бы объяснить. Общение начинается, когда один передает, а второй принимает сообщение. Но не пропускает "мимо ушей", слушая трафик, а реагируя, не обязательно ответом.

И очередь - прямо подразумевает, что НЕ одновременно, согласитесь? Иногда часа на 2-3 задержка... Иногда на сутки и годы... Но точно не одновременно.

TCP - два устройства одновременно, между ними устанавливается соединение.
UDP - может быть два (если один адресат), может быть больше для мультикаста.
ARP - вообще любое устройство, имеющее ip адрес, про включении в сеть начинает с бродкаста, то есть сообщения всем.
и, к слову, HTTP: при открытии страницы на этом форуме ваш браузер создаёт одновременно 9 TCP-соединений с разными серверами, и со всеми ними общается. Это если не считать DNS :)

Ни один из этих протоколов не обходится без L1. Да и очередь у любого из них начинается уже в стеке инициатора. Которая уприрается в линию до коммутатора. А у него своя очередь. Т.е. ни один из них не умеет в одновременность (если принять, что очередь - это не одновременно).
Попробую чутка позанудствовать (если принять, что очередь - это таки одновременнао):
TCP - TCP multicast есть. Но по физике, для получения ответа - все равно один физический порт. Даже, если в устройстве их несколько. Ответ придет только на один из них.
UDP - Ответ не требуется, но до назначения пакеты придут не одновременно.
ICMP - нечего вроде добавить
ARP - Протокол 2L, для его обработки, нет необходимости в IP адресе. Свитч и роутер может хранить таблицу MAC адресов, и отвечать не имея IP. И не немного не понятно, причем тут же HTTP, который через DNS разрешает адреса.

Это который ethernet через сеть ~230В? Там только полудуплекс и иного не может быть в принципе. Если имеется в виду что-то другое - модель устройства в студию.

Вот (https://www.ethernet-powerlink.org/file ... ng__1_.pdf)

омайнгот...

Вы меня перехваливаете )) Но приятно, что поняли таки, откуда "ноги у разных протоколов растут".

чего Вам и желаю.

Да какую паузу? Заканчивать пора.

Согласен.

Отправлено спустя 6 минут 53 секунды:

но вот реализации ТСР на разных ОС могут отличаться.

Может отличаться реализация стека (ака очереди), протокол соблюден будет. Иначе ваша ОС будет общаться только со своими собратьями.

При плохой связи ваша ОС может пытаться восстановить ТСР соединение, а со стороны ПЛК подумать что это совершенно новое подключение, такое иногда бывает когда сервер на чем-то nix'овом а клиент на винде. Следует копать в эту сторону.

Каждое TCP соединение всегда новое, если оно устанавливается повторно. Оно характеризуется исходящим портом и адресом и целевым портом и адресом. ОС вам не даст инициировать новое соединение, со старыми "реквизитами", вернет "порт занят" (должна вернуть, иначе там такая чехарда начнется).

ЗЫ: может для языка на котором у вас ПО есть библиотека реализующая S7 протокол ? Тогда стоило бы попробовать перейти на S7 протокол вместо modbus.

А зачем? В чем преимущества протокола S7 над Modbus в сторонних системах (если откинуть лицензию)?

[yoos86]

Может отличаться реализация стека (ака очереди), протокол соблюден будет. Иначе ваша ОС будет общаться только со своими собратьями.

к примеру - на windows просто так gracefull closing сокету не сделать

А зачем? В чем преимущества протокола S7 над Modbus в сторонних системах (если откинуть лицензию)?

конкретно для сименса - несколько активных подключений одновременно,и ненужно в проекте лишних заморочек для модбаса прикручивать.

[keysansa]

конкретно для сименса - несколько активных подключений одновременно,и ненужно в проекте лишних заморочек для модбаса прикручивать.

Согласен. Но модбас так же открыть на нескольких портах можно. Можно балансер в серединке поставить. Я правда не занимался вопросом опроса несколькими клиентами одного сервера Modbus по TCP. Вполне возможно, это уже решено. По крайней мере, я не вижу проблем.

ЗЫ. Для Modbus TCP, на 99%, это просто уход от последовательной топологии к звезде (когда умерший узел не приводит к падению связи всех узлов).

[VADR]

У нас это так и решено: на контроллерах поднято несколько modbus tcp серверов на разных портах, каждый клиент подкюачется к своему порту. На другой системе планируется (сейчас стадия проектирования) другой подход: в систему добавляется шлюз Anybus AB7650, допускающий одновременно до 8 клиентских подключений на один порт. Реально подключений будет одно или два: подключаться будет дублированная станция, а как там сделаны клиенты - пока не ясно: может быть один переключаемый мастер (так на этих системах Profibus реализован), может быть - два, каждый со своим адресом.

[fl4shback]

Up!
Кто-нибудь пытался поднять MB_Server для S1200 (1214C) с количеством holding-регистров, превышающим 248?
Столкнулся с проблемой, что когда выхожу за порог чтения/запись - дальше опрос регистров не идёт в принципе (MB_Client на другой стороне приёма пишет ошибку несуществующего адреса), хотя в документации указано, что 248 байт запроса - это максимальный запрос для одной итерации передачи данных, а остальные регистры, не вошедшие в посылку, кладутся в буфер переполнения "overflow_size_bytes", на сколько я понимаю... Может кто-нибудь подсказать в каком направлении копать, чтобы обойти эти грабли?
Тестируемое оборудование: мастер - S1500 (под MB_Client), слейв - S1200 (MB_Server)

[AlexandrGr]

выхожу за порог чтения/запись

Можно подробнее.

[fl4shback]

выхожу за порог чтения/запись

Можно подробнее.

Конечно!
Со стороны S1200 крутится MB_Server (в 1 экземпляре) с блоком данных длинной 807 байт, которые я использую одновременно для записи и для чтения посредством MB_Client'a.
Параметры:
MB_HOLD_REG: P#DB.. .DBX0.0 BYTE 807
Connect: HW72 (Profinet interface), ID = 1, Conn.Type = 11, Passive connect, remote port = 0, local port = 502.

Со стороны S1500 крутится MB_Client (в 1 экземпляре), на который в кейсе пробрасываю таргеты холдинг регистров, чтобы покрыть всю область блока данных для обмена с MB_Server, но без наслоения адресного пространства для чтения на пространство для записи.
Параметры:
Config DB: MB_Unit_ID = 1
MB_DATA_ADDR: 0-121,122-218, 314-409, 410-523, 524-639, 640-735, 736-807
MB_DATA_LEN: 121, 95, 95, 95, 113, 115, 95, 71
MB_MODE: 103 / 116

Под возвращаемой ошибкой чтения/записи, имел в виду MB_Client.Status = "8383" и MB_Client.Error.
Под "порогом чтения/записи" имел в виду пресловутые 248 байт (регистры 40000 - 40248).

Отправлено спустя 18 минут 21 секунду:
UPG:
В чём так же соль: если я опрашиваю транслируемые Holding-регистры MB_Server сторонним приложением, вроде Modbus Poll, то проблемы вообще никакой нет - вижу весь диапазон регистров, могу писать и читать каждый из объявленных регистров в диапазоне MB_Server.MB_HOLD_REG = P#DB.. . DBX0.0 BYTE 807. Но налаживаю связь между двумя S1200 и S1500 и ловлю в лицо грабли с ограничением чтения/записи.

[M3f]

fl4shback, лучше один раз увидеть, чем сто раз услышать, поэтому хотелось бы увидеть код.
1. Непонятно, когда вы читаете, а когда пишите в эти адреса? И как это у вас организованно?
2. Когда конкретно, на каком шаге, возникает ошибка "8383"? Вы мониторите статус в каждом цикле или просто смотрите в DB?

Пока вижу только возможные проблемы в задании адреса на MB_SERVER и адресов при опросе у MB_CLIENT.
У вас адрес на MB_SERVER: P#DB.. .DBX0.0 BYTE 807 (или P#DB.. .DBX0.0 WORD 403), а адреса на MB_CLIENT вы задаете больше 403.
Например, если вы задаете на MB_SERVER: P#DB10.DBx0.0 BYTE 10 (или P#DB10.DBx0.0 WORD 5), то можете читать только с 40001-40005 (DB10.DBW0 - DB10.DBW8).

[fl4shback]

fl4shback, лучше один раз увидеть, чем сто раз услышать, поэтому хотелось бы увидеть код.
1. Непонятно, когда вы читаете, а когда пишите в эти адреса? И как это у вас организованно?
2. Когда конкретно, на каком шаге, возникает ошибка "8383"? Вы мониторите статус в каждом цикле или просто смотрите в DB?

Пока вижу только возможные проблемы в задании адреса на MB_SERVER и адресов при опросе у MB_CLIENT.
У вас адрес на MB_SERVER: P#DB.. .DBX0.0 BYTE 807 (или P#DB.. .DBX0.0 WORD 403), а адреса на MB_CLIENT вы задаете больше 403.
Например, если вы задаете на MB_SERVER: P#DB10.DBx0.0 BYTE 10 (или P#DB10.DBx0.0 WORD 5), то можете читать только с 40001-40005 (DB10.DBW0 - DB10.DBW8).

Вот это фейл с моей стороны
Я как-то на автомате считал MB_ADDR и MB_LEN в тех же байтовых размерах, а 4xxxx - это ведь указатель на ворды *лицо-рука*
Пошёл тестить:) спасибо огромное