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

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

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

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

Цитата:

---

Сообщение от tkont

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

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

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

---

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

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от Мастеренко Иван

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

---

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

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от capzap

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

---

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

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

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

Цитата:

---

Сообщение от capzap

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

---

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

поскольку в 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шках
что бы работало
Вложение 44742

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

Вложение 44737

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от capzap

продолжайте игнорить очевидные вещи, черным по белому в спецификации написано каков адрес для ширковещательного запроса, (см.скрин)
перевод слова 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 не доберутся

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от capzap

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

---

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

Цитата:

---

Сообщение от tkont

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

---

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

Цитата:

---

Сообщение от Santi

То, что адрес ModBusRTU для подключения конфигуратора является и ID для предоставляемых пользователю данных в ModBusTCP мне бы (без доп.комментариев) в голову сразу не пришло.

---

А в каком месте Конфигуратору для подключения нужен адрес Modbus? Что-то я не увидел.
А вот с тем, что именно адрес слейва нужно указывать при подключении по Modbus/TCP - у меня лично вопросов не возникло. Может быть потому, что до этого с подобными дело имел. Правда, эти подобные представляли из себя шлюзы в RTU, т.ч. там все логично.

Фиг его знает, может эти Mx210-е внутри как шлюзы устроены. Правда непонятно - зачем это наружу показывать?
А может просто по инерции. Помнится, для общения с ПЛК100 по Modbus/TCP мне тоже в настройках адрес нужно было явно указывать.
Но, тут не знаю - может быть это от настройки/программирования самого ПЛК зависит.

Так то, конечно, чистому Modbus/TCP никакой адрес Modbus не нужен, фактически адрес указывает для устройств, которое лежит за устройством Modbus/TCP.

Кстати, разработчики вполне адекватно отреагировали. КМК. О чём спор?

Цитата:

---

Сообщение от imaex

О чём спор?

---

куда склонять разработчиков -
к UNIT_ID not used или к "постоянной валидности" UNIT_ID при 0xFF и 0x00

устраиваем голосование :)
сразу говорю - мне без разницы какой вариант

Цитата:

---

Сообщение от capzap

опять пытаетесь все вывернуть, в спецификации 255 адрес зарезервирован

---

не правда
он не зарезервирован, это адрес используется в TCP там где нужно, смотрите спецификацию, только не RTU а TCP
я беру с официалки, прямо с ORG
4.4.1.3 Process MODBUS Confirmation
Вложение 44755

Цитата:

---

Сообщение от tkont

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

---

Не надо, нам и так хватит работы ;)

Всем привет! Люди, помогите решить вопрос с коннектом этого модуля. МВ_client v5.2, корректность настройки проверена на других приборах, все работает идеально, а с этим, блин… В настройка DB mb_client в переменной unit ID уже изменил с 16#FF на 16#01, как писалось выше, не работает!

Добрый день.

Можно, пожалуйста, больше информации:
- другие модули, это модули серии Мх210 ил сторонних вендоров?
- проверяли связь конкретного образца с конфигуратором/другим мастером ModbusTCP?

Добрый день!

S7-1200 + MB210-101.
На котроллере сконфигурирован Modbus Client (Master) для MB210-101. Регистры не читаются, никакие. Пробовал в разных комбинациях - статус показывает обмен данными, но сам модуль мигает красным (ошибка обмена).
При этом на тех же настройках ModbusSlave (утилита для ПК) пишет регистры и они нормально читаются.

Для MB210-101 обновлял прошивку. Пока идеи что делать дальше закончились.
Модуль 76264210932373432.

Цитата:

---

Сообщение от capzap

настройки то увидим или закладываетесь на экстрасенсорные способности форумчан

---

Настройки контроллера или модуля?
С контроллером всё стандартно. В S7-1200 пробовал 16#00, 16#01, 16#FF - изменений нет. По статусу 7004/7006 без ошибок. Регистры пустые, начиная с первого.
Про MB210-101 - там настроек (кроме IP адреса), касающихся связи - нет. Адрес Slave поменять нельзя.

Цитата:

---

Сообщение от capzap

ну не все же заключается только в назначении UnitID, модуль и плк в одной сети и пингуются, по какому адресу посылает запрос (RemoteAddress из TCON_IP_v4), какой MB_MODE стоит и т.д.

PS вот видос, у него тоже сперва были проблемы в районе 13 - 15 минуты смотреть,

---

Модуль (192.068.0.67) и ПЛК (192.168.0.66) в одной сети, шлюз 192.168.0.1 и маска 255.255.255.0 общие.
RemotePort 502, MB_MODE 0 (Read).
Видос этот уже видел. С программой работает, с модулем - нет(

UPD: Модуль виден через конфигуратор и по USB, и по Ethernet.

Добрый день.
Можете предоставить удаленный доступ по team viewer/anydesk и подключить модуль напрямую к ПК?

Цитата:

---

Сообщение от Мастеренко Иван

Добрый день.
Можете предоставить удаленный доступ по team viewer/anydesk и подключить модуль напрямую к ПК?

---

Добрый день! Да, без проблем.

Есть некоторый прогресс и странности работы модуля.
Модeль не отвечает на групповой запрос чтения регистров. Т.е. я могу читать (и через Siemens, и через Modbus Poll) максимум 4 регистра одновременно, при попытке считать большее количество вылетает ошибка illegal data address.

Какой диапазон адресов регистров , например, читаете ?

Цитата:

---

Сообщение от Мастеренко Иван

Какой диапазон адресов регистров , например, читаете ?

---

Сейчас работает с 26, 4 регистра. Меньше - без проблем, больше - ошибка.
Также пробовал с 4000 - тоже 4, работает.

UPD: Разобрался, всё работает.

В общем должен сказать что есть 2 момента, которые считаю необходимым озвучить:
1. Я допустил ряд ошибок, в связи с чем были проблемы с работоспособностью модуля. Полностью признаю это.
2. Модуль работает достаточно стабильно без особых проблем, по крайней мере на текущий момент. Дальше будем смотреть.

Возник вопрос по ходу эксплуатации.
Для тестирования настроено следующим образом:
- включен канал измерения №2, остальные отключены
- канал №2 настроен на работу с термопарой ТХА(К)
- данные читаются по Modbus группой регистров, 4000-4023 (24 регистра)
Значения в контроллере и в модуле (через Owen Configurator) совпадают.

Проблема в том, что значения температуры не соответствуют реальным.
Т.е. в реальности температура 24, модуль показывает 18. Причём при нагревании ошибка разности показаний увеличивается. Такое ощущение что НСХ не соответствует выбранному типу.
Термопара проверена отдельным вторичным преобразователем.

Что может быть?

Приложите скриншот настроек 2 канала из конфигуратора.

Вложение 57680
Скрин сделал.

Цитата:

---

Сообщение от doctor.542

Вложение 57680
Скрин сделал.

---

В конфигураторе нажмите кнопку "Юстировать устройство", выберите тип измеритель температуры холодного спая и далее следуйте по инструкции.

Цитата:

---

Сообщение от Мастеренко Иван

В конфигураторе нажмите кнопку "Юстировать устройство", выберите тип измеритель температуры холодного спая и далее следуйте по инструкции.

---

Написано подключите термопару, на рисунке термосопротивление. Что подключать в итоге?
Вложение 57686

Цитата:

---

Сообщение от doctor.542

Написано подключите термопару, на рисунке термосопротивление. Что подключать в итоге?
Вложение 57686

---

Термопару. Картинку поменяем, спасибо.