МК210 + PLC (S7-1200 и др.)

[tkont]

столкнулся с тем что МК210-312 не может установить связь с SIMENS S7-1200 , после некоего поиска выяснилось связь возможна если в настройках мастера (клиента) установлен адрес слейва равный "1" (по умолчанию в клиенте MB TCP адрес слева "FF")
т.е. микропрограмма МК210-312 в обязательном порядке мониторит адрес слейва, при этом в настройках через конфигуратор адрес модуля поменять нельзя, настроен жестко единицей без возможности изменения.
скрин во вложении

если уж обязательно и есть какой то тайный смысл мониторить в MB TCP адрес слейва - то возможно ли сделать (примечание для разработчиков модуля) адрес "Адрес Slave = 255" как широковещательный (и по умолчанию установленный) , то есть SLAVE будет принимать любые адреса (т.е. не мониторить вообще)
тем более что допустимо вообще не мониторить (скрин во вложении)

просьба решить этот вопрос в будущих прошивках в МК210 с MODBUS TCP , тем (посылка с адресом "FF" принимается всегда) или иным способом (не мониторить вообще) или если настройка адреса слейва "FF" в модуле то принимаются любые адреса или какой либо др. вариант.

[Мастеренко Иван]

столкнулся с тем что МК210-312 не может установить связь с SIMENS S7-1200 , после некоего поиска выяснилось связь возможна если в настройках мастера (клиента) установлен адрес слейва равный "1" (по умолчанию в клиенте MB TCP адрес слева "FF")
т.е. микропрограмма МК210-312 в обязательном порядке мониторит адрес слейва, при этом в настройках через конфигуратор адрес модуля поменять нельзя, настроен жестко единицей без возможности изменения.
скрин во вложении

если уж обязательно и есть какой то тайный смысл мониторить в MB TCP адрес слейва - то возможно ли сделать (примечание для разработчиков модуля) адрес "Адрес Slave = 255" как широковещательный (и по умолчанию установленный) , то есть SLAVE будет принимать любые адреса (т.е. не мониторить вообще)
тем более что допустимо вообще не мониторить (скрин во вложении)

просьба решить этот вопрос в будущих прошивках в МК210 с MODBUS TCP , тем (посылка с адресом "FF" принимается всегда) или иным способом (не мониторить вообще) или если настройка адреса слейва "FF" в модуле то принимаются любые адреса или какой либо др. вариант.

Здравствуйте!
Уже поставили задачу, чтобы Мх210 помимо запросов со своим адресом отвечали на запрос с адресом 255. Спасибо за конкретику.

[tkont]

а почему в сименс не пишите, может быть это им следовало изменить значение по умолчанию

ну в данном случае , с МК210 - конечно пришлось менять в сименсе , иначе не подключится - на скрине даже подписал переменную что менять в сименсе
а так все модули и панели что подключаем работают с "FF" , вот только у МК210 получилось совсем не так как у остальных
FF широковещательный как известно, уж даже если так формально подходить - МК210 должен был принять с FF

хотя полагаю они это сделали специально чтоб у программистов ни чего не получалось пока они не выставят соответствующий адрес

понимаю если бы эту функцию в конфигураторе овена не заблочили, так нет - и адрес модуль мониторит (контроль и так идет на уровне TCP IP а тут еще и адрес добавили) , так кроме того что контролирует по нему - его еще и поменять нельзя

[tkont]

Здравствуйте!
Уже поставили задачу, чтобы Мх210 помимо запросов со своим адресом отвечали на запрос с адресом 255. Спасибо за конкретику.

пока писал ответ на пост выше - уже ответили
спасибо - буду ждать прошивки

[tkont]

я специално выделил какой адрес в модбасе широковещательный, поэтому вопрос кому известно?

в спецификации MB RTU есть широковещательный 255, с тех пор и тянется

то что в локальной сети последний байт адреса равный 255 это широковещательный ни какого отношения не имеет к протоколу

все что вверху говорилось , говорилось про адрес в слейва в MBAP а не в IP хидере
выделил красным в структуре на картинке
ну надеюсь ребята из овена и без картинок должны были понять про баг с адресом "01" слейва что намертво вшит в модуль , естественно не в IP а в MBAP Header
STR_MB_TCP_ADR.jpg

[Santi]

Если устройство ModBusTCP привязано к определенному ID - это нормально, только в описании на ус-во это д. б. указано, чтобы пользователь не тыкался перебирая 256 раз.
В описании на МК210 это указано?

[Santi]

То, что адрес ModBusRTU для подключения конфигуратора является и ID для предоставляемых пользователю данных в ModBusTCP мне бы (без доп.комментариев) в голову сразу не пришло. А где-то еще в нескольких местах по руководству не увидел. Так что я, как и топик, а может еще и другие пользователи, ознакомившись с руководством имел бы аналогичный вопрос.
Но интересует эта тема меня мало, можете считать мое сообщение просто репликой, а не вопросом к Вам, capzap.

[tkont]

в спецификации говорите, нука ссылочку? Попытайтесь оспорить выдержку из скрина

на том скрине что вы в посте скинули и указанно про 255 в заголовке MBAP , я бы и тот же и скинул
в принципе могу скинуть , что бы дополнительно выделить
MBAP_TCP_UNIT_FF.jpg

поскольку в MODBUS TCP
# 0xFF (recommended as non-significant value) or 0x00
то что бы следующий товарищ, кому вдруг понадобится "0x00", поскольку он где то там в недрах мастера намертво прошит
то надо уж сразу все проверить UnitID на возможные варианты (что должны пройти как "допустимые в работе") по спецификации modbus tcp

if (ADUget.UnitID == 255 || ADUget.UnitID == 0 || ADUget.UnitID == ADUset.UnitID ) {
	ADUsend.UnitID = ADUget.UnitID ; 
	MY_parsing_function () ;
}

мне пока нужен 255 (0xFF)

У меня сименс конечно можно перенастроить, но хотелось бы что бы работали на стандартных DBшках
что бы работало
MBAP_TCP_PROFACE.jpg

и про RTU и broadcasting = 255
вдруг еще кто еще задаст вопрос про широковещательный 255 в RTU (он же по спецификации "0x00"), то что бы не спорили , то на скрине :
MB_RTU_BC_255.jpg

MB__BC_255.jpg

так еще и пользуется не обновленным конфигуратором, у него максимальный адрес 0xFF, а у меня 0xFE

у меня свеже-скачанный на момент старта топика - v1.16.82.19020

[tkont]

продолжайте игнорить очевидные вещи, черным по белому в спецификации написано каков адрес для ширковещательного запроса, (см.скрин)
перевод слова non-significant так и сквозит широковещательностью

ЗЫ из справки сименсапоэтому не понятно с кем Вы там "боретесь" используя MB_UNIT_ID

вот именно что - not used было бы в самый раз

not used in the case of Modbus TCP addressing.
но овен то пошел своей тропинкой
он этот адрес использует и контролирует - если не выставишь в мастере тот который в конфиге модуля , то модуль не отвечает
с этого и начался топик - про UNIT_ID
его бы вообще не мониторить в модуле, поскольку запрос уже адресован конкретному IP, так нет - в модуле еще и мониторится UNIT_ID , который должен быть not used
ну если уж так приспичило им мониторить , пусть пускают хотя бы FF и 00 по умолчанию как валидные, если до not used не доберутся

[tkont]

и я начал с того что обычно это прерогатива клиента выставлять адрес, у семена это одно присвоение в коде, не нравиться пишите им письма чтоб соответствовали

на форуме когда светится баг - быстрее исправят ошибку чем писать письма в черную дыру

но ни как заставлять производителя слейва отходить от спецификации

заставлять овен - соответствовать спецификации что бы not used - бесполезно, не заставишь
я поэтому и выше в первом посте и указал , хотя бы той части соответствовать где

(посылка с адресом "FF" принимается всегда)

хотя бы эту часть исполнят и то считай подарок
даже про 0x00 ни чего не говорил что бы не нагружать и так загруженных софтописателей...