Вопрос по Modbus TCP/IP (Возможно так задумано)

[Ilya J.]

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

Видимо эти параметры должны были передаваться в этой строке

Ifx=0xbc0,0xbc2,0x117,0xa0c,0xa10,0xa14,0xbc4,0xa18

Как один из скрытых для блока
Вложение 11365

Сделали, но не в этой строчке, а как и в вашем примере.

alf999, проверьте в актуальной версии(3.34.210) ваши проекты.

[ATS]

Сообщение от Ilya J.

Сделали, но не в этой строчке, а как и в вашем примере.

Да главное чтобы работало. Проверю.

[alf999]

Сообщение от Ilya J.

Сделали, но не в этой строчке, а как и в вашем примере.

alf999, проверьте в актуальной версии(3.34.210) ваши проекты.

Проверил... мдя... похоже что то с драйвером.

Результат:

1) Всего 1 блок:
На одном блоке в ручном режиме (Управление из FBD) - работает и задержка и можно отключить при необходимости опрос, устройство отвечает как положено без прерываний.

2) всего 10 блоков:
9 блоков в режиме автомат и не отвечают, 1 в ручном режиме (Управление из FBD) и устройство отвечает.
- тоже вроде как все работает.

3) всего 10 блоков:
8 блоков В режиме автомат и 2 в ручном режиме и 1 из этих 2х не доступен.
- Тут снова начинаются проблемы:
Опрос 1 доступного устройства начинает сбоить (нет опросов 1 устройства на момент опросов 2 устройства а именно в момент паузы между таймаутами опроса 2 устройства). Как только 2 устройство уходит на время возобновления опроса (Длинный таймаут) 1 устройство опрашивается как положено.

Пока проверил только это в тестовом проекте, в моем проекте с ручным управлением опять получается белиберда Прекращается опрос устройств как будто опрос идет не 5 нитками (параллельно), а одной задачей (последовательно каждый слейв)...

Чуть позже проверь детальнее.

SMlogix обновил и форматировал контроллер перед проверкой. Изменения заметны. но с ручным режимом всеравно беда...

[Ilya J.]

Блоками вы устройства-слейвы называете?

[alf999]

Сообщение от Ilya J.

Блоками вы устройства-слейвы называете?

Да SlaveX (Link), Slave (Link).

[Arsie]

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

Да SlaveX (Link), Slave (Link).

Проект с 10 слейвами приложите?

[alf999]

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

Проект с 10 слейвами приложите?

Возьмите Test1.psl с устройством из Modbus Slave который был ранее в этой теме. Там 10 слейв (11 соврал), но 1 ведет себя не адекватно у меня, в ручном режиме на несуществующий IP не выдаёт ошибок.

Могу снять видео...


Добавлено через 2 минуты

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

Такс... потратив час на кусок моего проекта всего лишь с 1 ибп и 10 датчиками... в общем получается 11 устройств. В проекте только часть опроса и преобразование в нужные данные по описанию регистров от производителя датчиков.

Не забудьте поменять IP адрес у блока опроса на тот, где будет запускаться Modbus Slave и ну и соответственно запустить слейв (Connect).
Приложил на всякий случай используемые макросы...

В этом сообщении

[Arsie]

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

Возьмите Test1.psl с устройством из Modbus Slave который был ранее в этой теме. Там 10 слейв (11 соврал), но 1 ведет себя не адекватно у меня, в ручном режиме на несуществующий IP не выдаёт ошибок.

Приложите конкретный проект и укажите, какие конкретно слейвы на линии и какие конкретно слейвы не на линии.

Мы ничего себе придумывать не будем, проходили это уже много раз. Вы либо разбирайтесь сами, либо точно по шагам рассказывайте, как нам повторить то, что происходит у вас.

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

Могу снять видео...

лог сниффера был бы полезен. Видео не имеет смысла вообще.

[alf999]

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

Приложите конкретный проект и укажите, какие конкретно слейвы на линии и какие конкретно слейвы не на линии.

Мы ничего себе придумывать не будем, проходили это уже много раз. Вы либо разбирайтесь сами, либо точно по шагам рассказывайте, как нам повторить то, что происходит у вас.





лог сниффера был бы полезен. Видео не имеет смысла вообще.

Хорошо, завтра все приложу

[alf999]

Вот программа Test.1 (она же которая была ранее), но на всякий случай снял видео того что происходит, и файл программы, файл тестового slave устройства, и файл с логами Slave рабочего устройства прикрепил.

Видео:
https://cloud.mail.ru/public/gQMP/854F1ibmY

Опишу нынешнюю проблему вкратце:

Если slave устройство не отвечает и идет счет ошибок до выхода устройства на длинный таймаут (например до перерыва на длинный таймаут 5 попыток), то в этот момент перестает отвечать нормально работающий Slave. То есть пока один блок SlaveX (Link) пытается опросить устройство, другой блок SlaveX (Link) прекращает свой опрос.

По логике, опрос устройства рабочего не должен прекращаться, если у нас другое не отвечает. (не знаю как это реализовано у вас).

[alf999]

Работы над этим вопросом ведутся?, ждать решения?

[Arsie]

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

Работы над этим вопросом ведутся?, ждать решения?

Я пока не уверен, есть ли проблема.

[alf999]

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

Я пока не уверен, есть ли проблема.

Если в теории, то работа с COM портом была бы корректна в таком примере, т.к. там идет последовательный опрос устройств, и время ожидание ответа тормозит следующий опрос.

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

[Arsie]

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

Если в теории, то работа с COM портом была бы корректна в таком примере, т.к. там идет последовательный опрос устройств, и время ожидание ответа тормозит следующий опрос.

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

Вы мыслите рамками сферического коня в вакууме, т.е. рамками системы с бесконечным количеством ресурсов. Каждое устройство или экземпляр протокола в эзернете это своя "виртуальная машина", требующая вполне определённых ресурсов. Количество "виртуальных машин" всегда ограничено. Где-то больше, где-то меньше. Но всегда ограничено.

Ваш пример с СОМ-портом весьма к месту. Там может быть всего одна "виртуальная машина", поэтому опрос и работает исключительно последовательно.


PS. Термин "виртуальная машина" условен.

[ATS]

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

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

Даже с COM портом можно последовательно кинуть запросы разным устройствам и ждать ответы. Но есть шанс получить коллизии.

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

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

[alf999]

У меня есть на руках контроллер Beckhoff cx9010 с процессором (533 МГц Intel® IXP420). работающий на "Microsoft Windows CE" с "Codesys" на борту (Если точно то на TwinCAT), Который с такими мелкими ресурсами спокойно опрашивает 67 modbus TCP/IP устройств, без всяких задержек. Дело не в железе, дело в реализации алгоритмов...
Вы ставите мощное железо, рекламируете, а в итоге получается что Ethernet это Com порт... (Извините, накипело )

Я понимаю сложность разработки устройства (PLC). И прошу прощения за мои вопиющие высказывания...

Прошу понять меня как пользователя вашей продукции, зарубежные контроллеры официально перестали поставлять на рынок РФ, поэтому приходится искать альтернативы. Ждать производства вашей продукции долго, и некоторые фирмы на этом зарабатывают, скупают у вас продукцию и перепродают в 6-7 раз дороже цен завода изготовителя из за дефицита. (Заплатив в 6 раз дороже я получил красивый контроллер с мощным железом и COM портом в Ethernet, и смешно и грустно...).

на счет Ethernet что это последовательный интерфейс - это понятно, только отличия в скоростях, методах, и возможностях... Например одновременная передача и чтение информации (дуплексный режим)... В которой можно и не ждать несколько секунд ответа от устройства, до отправки новых пакетов другим разным устройствам...

[Arsie]

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

У меня есть на руках контроллер Beckhoff cx9010 с процессором (533 МГц Intel® IXP420). работающий на "Microsoft Windows CE" с "Codesys" на борту (Если точно то на TwinCAT), Который с такими мелкими ресурсами спокойно опрашивает 67 modbus TCP/IP устройств, без всяких задержек. Дело не в железе, дело в реализации алгоритмов...
Вы ставите мощное железо, рекламируете, а в итоге получается что Ethernet это Com порт... (Извините, накипело )

Вы занимаетесь, простите, звездобольством. Мы ещё не разобрались в ситуации, а вы уже "ЖГИ ВЕДЬМУ" разорались.

Ещё и девайс на ВинСЕ приплели. Вообще тёплое с мягким. ВинСЕ на нашей платформе вообще не запустится, ОЗУ не хватит. Т.е. не опросит ни одного устройства.

[alf999]

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

Вы занимаетесь, простите, звездобольством. Мы ещё не разобрались в ситуации, а вы уже "ЖГИ ВЕДЬМУ" разорались.

Я же извинился далее ...

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

Ещё и девайс на ВинСЕ приплели. Вообще тёплое с мягким. ВинСЕ на нашей платформе вообще не запустится, ОЗУ не хватит. Т.е. не опросит ни одного устройства.

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

На счет того что еще не разобрались - так и надо было ответить (что то вроде мы работаем над вашем вопросом и т.д.)...

Просто тема на форуме потихоньку начала двигаться вниз, ответов нет, и вы написали что не уверены что есть проблема... Я конечно не разработчик вашего контроллера, но по моему мнению он должен работать немного по другому чем есть на самом деле (это касательно только моей проблемы, а именно обмен по TCP/IP). Считаю что если есть возможность то ее нужно использовать. Либо описать в документации почему так нельзя, иначе всегда будут возникать вопросы.

[Arsie]

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

Просто тема на форуме потихоньку начала двигаться вниз, ответов нет, и вы написали что не уверены что есть проблема...

Да. я не уверен. Но исследование всё равно мы проведём. Всему своё время и своя очередь.

[Ilya J.]

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

[ATS]

Сообщение от Ilya J.

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

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

[alf999]

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

Проверил... мдя... похоже что то с драйвером.

Результат:

1) Всего 1 блок:
На одном блоке в ручном режиме (Управление из FBD) - работает и задержка и можно отключить при необходимости опрос, устройство отвечает как положено без прерываний.

2) всего 10 блоков:
9 блоков в режиме автомат и не отвечают, 1 в ручном режиме (Управление из FBD) и устройство отвечает.
- тоже вроде как все работает.

3) всего 10 блоков:
8 блоков В режиме автомат и 2 в ручном режиме и 1 из этих 2х не доступен.
- Тут снова начинаются проблемы:
Опрос 1 доступного устройства начинает сбоить (нет опросов 1 устройства на момент опросов 2 устройства а именно в момент паузы между таймаутами опроса 2 устройства). Как только 2 устройство уходит на время возобновления опроса (Длинный таймаут) 1 устройство опрашивается как положено.

Пока проверил только это в тестовом проекте, в моем проекте с ручным управлением опять получается белиберда Прекращается опрос устройств как будто опрос идет не 5 нитками (параллельно), а одной задачей (последовательно каждый слейв)...

Чуть позже проверь детальнее.

SMlogix обновил и форматировал контроллер перед проверкой. Изменения заметны. но с ручным режимом всеравно беда...

Вот описал, на 1 работает, и в автомате и в ручном режиме (Управление из FBD)... на 1 в ручном и 9 в автомате, работает... но как добавляю 2 в ручном и 8 в автомате, то появляются задержки в опросе. при чем задержки я мониторю со стороны слейва. а не со стороны контроллера, т.к.у контроллера в подглядчике ничего не происходит, все работает штатно.

[Arsie]

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

Вот описал, на 1 работает, и в автомате и в ручном режиме (Управление из FBD)... на 1 в ручном и 9 в автомате, работает... но как добавляю 2 в ручном и 8 в автомате, то появляются задержки в опросе. при чем задержки я мониторю со стороны слейва. а не со стороны контроллера, т.к.у контроллера в подглядчике ничего не происходит, все работает штатно.

Контроллер в подглядчике показывает фактологию. Т.е. если переменная RW показала число на выходе, то произошла фактическая запись и произошло фактическое чтение.

А уж что там у вас и насколько достоверно показывает слейв, это нас не касается.

[alf999]

Посмотрите что происходит на видео приложенном с проектом на котором это тестировалось. Можете повторить?

1) Запустить программку "modbus slave" открыть в ней файл Test1.mbs, нажать connect (устройство симулируется).
потом нажать пункт меню Display - Communication...
и посмотреть когда и как пойдут вопросы от контроллера и ответы от компьютера.

2) Взять файл Test1.psl и залить на контроллер матрикс.
на одном из slaveX указать адрес своего компьютера (на котором запущен modbus симулятор).

Посмотреть что через несколько секунд работы вопросы от контроллера на компьютер начинают дико тормозить (хотя нет никакой причины и аварии). А тормозят они ровно в тот момент, когда на соседнем блоке начинается ожидание ответа и попытки связи с нерабочим slave.


Добавлено через 5 минут

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

А уж что там у вас и насколько достоверно показывает слейв, это нас не касается.

Простите... как это?, т.е. если вы убеждены что контроллер работает верно, то и проверять не надо... ибо это вас не касается?

При чем тут пример с записью переменной?

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

[Arsie]

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

Посмотрите что происходит на видео приложенном с проектом на котором это тестировалось. Можете повторить?

1) Запустить программку "modbus slave"

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


Добавлено через 1 минуту

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

Простите... как это?

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

[alf999]

Мы обычно используем живые слейвы.

Да не вопрос, какой программой снять лог?

[Arsie]

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

Хорошо, если вам лень

Мы привыкли действовать последовательно.

Исследование номер 1: вы декларировали, что у нас работа на TCP построена как на СОМ, строго последовательно. Пример Ильи показал, что вы не правы и не до конца владеете созданной вами ситуацией.

Далее будет исследование номер 2 и номер 3.

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

Да не вопрос, какой программой снять лог?

Поздно уже, сами разбираемся.

[alf999]

Во первых, нафига я скидывал программу, видео, лог, имитацию устройства... если ее все равно не кто не смотрит, и не читает то что было написано выше, что на 1 устройстве все работает...

Привели пример программы, я глянул там максимум 3 устройства (1 из которых на COM). И ни кто не написал что происходит со стороны слейва (посмотреть как идет общение в сети). То что оно прерывается... (то что видел я и то что заснято на видео) а со стороны отладчика все норм...

[ATS]

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

Во первых, нафига я скидывал программу, видео, лог, имитацию устройства... ..

На реальных устройствах проверяли? Советую попробовать.

[Arsie]

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

Во первых, нафига я скидывал программу, видео, лог, имитацию устройства... если ее все равно не кто не смотрит, и не читает

Всё смотрим и всё читаем. Ищем, где вы ошиблись. Из ваших записей это не очевидно. Поэтому исследуем сами.