Вход

Просмотр полной версии : ПЛК 110 и опрос по Modbus TCP



Паэлпапаэл
18.05.2015, 22:28
Здравствуйте! Частые потери связи, либо затыки, после которых связь можно восстановить сбросом питания, либо долгим перетыканием портов кабелей связи двух ПЛК.
Прошу помочь разобраться в следующем:
имеется система управления, в её составе 2 ПЛК110-24.60.Р-М, одна панель оператора Weintek MT-8070iH, а также, осуществляется опрос ПЛК от компьютера диспетчера.
Использование 2-ух ПЛК предусматривалась в том ключе, что один из ПЛК - ведущий, другой - резервный, который перехватывает на себя управление системой в случае выхода из строя первого ПЛК (ведущего).
Для этого ПЛК общаются между собой посредством Modbus TCP, первый ПЛК (ведущий) - Мастер, второй ПЛК - Slave. Из одного ПЛК в другой передаем одни Слова, другие - принимаем.
IP адрес 1-ого ПЛК:20:1:51:96
IP адрес 2-ого ПЛК:20:1:51:97
Применяем стандартный блок Universal Modbus Device. Его настройки - на рисунке.
18203

Не совсем понятно, какой параметр выставлять в строке Byte Sequence, поскольку вроде как в документации указано, что ставим Native - порядок бит для ПЛК, но вроде и при Trace Mode работает. Трудно проследить правильность выбора, поскольку и другие факторы тоже вмешиваются. Игрались и с режимом опроса (Work Mode), и с временем опроса (при выборе By Poll Time). Оптимальный вариант не нашелся. Вроде как лучше все же с этой конфигурацией, приведенной на рисунке выше.
Чтобы полностью картину описать, поясним, что в системе ещё есть панель оператора, она является Slave-ом. Оба ПЛК - Мастеры в этом случае. С ней мы общаемся тоже по Modbus TCP, порт 800.
IP адрес панели:20:1:51:104
Настройки панели для опроса ниже (для опроса 1-ого ПЛК):
18205

Для 2-ого ПЛК, соответственно, другие IP адреса, в остальном - аналогично.

Также, оба ПЛК опрашиваются АРМ оператора, тоже Modbus TCP, порт 502. Период опроса - 200 мс.

Проблема в том, что довольно часто происходят обрывы, либо вообще затыки связи, от нескольких раз в день до нескольких раз в час. Обрывы чаще между двумя ПЛК. Ошибка выходила раньше и 81, и 85. Сейчас уже, вроде как, 81 наблюдается намного чаще. Даже бывает такое, что связь обрывается, не выдавая ошибку. Просто прекращается передача данных, и все на этом. Именно вот эта проблема интересует БОЛЬШЕ ВСЕГО! Были обрывы связи с панелькой оператора, но после того, как установили время ожидания 5с, тогда обрывов пока не наблюдалось, либо они не такие частые просто).

Очень нужно поскорей решить проблему, потому что месяцы ковыряний и наблюдений слишком затянулись. Ребят, используем кучу оборудования Овен, от модулей МВ110 до ПЧВ3, и рассчитываем на помощь, дружественную и искреннюю!!!!

capzap
18.05.2015, 22:40
без обид, но наместе устройств я бы тоже с Вами не связывался, что это вобще ip-адреса как мак-адреса пишите? в место специально отведенных адресов под локальные сети используете занятые американцами подсети?

Паэлпапаэл
18.05.2015, 22:46
Использовали на другом объекте 192.168.0.240 и т.д , но такая же ситуация. Но адреса и не мы задаем, нам их предписывают задавать именно такие, как указано в первом посте. Больше вопрос по настройкам опроса между двумя ПЛК, и в частности про Byte Sequence.

capzap
18.05.2015, 22:51
Использовали на другом объекте 192.168.0.240 и т.д , но такая же ситуация. Но адреса и не мы задаем, нам их предписывают задавать именно такие, как указано в первом посте. Больше вопрос по настройкам опроса между двумя ПЛК, и в частности про Byte Sequence.

секвенс это как разногласия в произведениях Свифта, для связи роли не играет каким байтом вперед передавать информацию

Паэлпапаэл
18.05.2015, 23:01
Подскажите пути решения проблемы и ткните на те ошибки, которые вы увидели в описании нашей ситуации лучше. К чему Свифт и американские подсети???

capzap
18.05.2015, 23:12
свифт высмеивал войну сторонников разбивать яйцо с тупой и острой стороны,так и Вы ищите проблему как в протоколе будут укладываться байты данных, ТСР в любом случае передаст единички нолики в полном объеме не разрывая соединение

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

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

Паэлпапаэл
18.05.2015, 23:23
Поднималась на форуме тема про связь ПЛК посредством Netvar UDP, это может чем-то помочь, и более ли правильно таким образом делать опрос?

Паэлпапаэл
18.05.2015, 23:40
Прикладываю ПО

Sergey666
18.05.2015, 23:56
А данные , когда обмен нормальный , корректные приходят???
У вас чудовищно сконфигурирован модбас слэйв , расположение в конфигураторе слэйв-мастер-слэйв может приводить к "наползанию" данных слэйва на область памяти мастера . Слэйвы надо размещать внизу конфигурации.
В Мин.ц ПЛК поставить 5 на обоих , с вашим конфигуратором наверняка нехват ресурсов процессора (курить ему некогда , да и выпить тоже:)).

Паэлпапаэл
19.05.2015, 00:05
Спасибо!!!
Мин.ц ПЛК - это MinCycle Lenght?
Так а что, действительно, данные слэйва могут наползать на данные мастера? Так если мы вниз слэйвы переместим, то они друг на друга тогда наползать будут. Так что-ли?

А данные, да, нормальные идут.

Sergey666
19.05.2015, 00:40
Спасибо!!!
Мин.ц ПЛК - это MinCycle Lenght?
Так а что, действительно, данные слэйва могут наползать на данные мастера? Так если мы вниз слэйвы переместим, то они друг на друга тогда наползать будут. Так что-ли?

А данные, да, нормальные идут.

Если сейчас данные нормальные идут , то значит пока ОК. Если в последствии (далее) добавлять данные в слэйв перед мастером могут быть "наползания" .

Паэлпапаэл
19.05.2015, 00:54
Т.е. как я понимаю, пока имеет смысл только увеличить время цикла программы?

capzap
19.05.2015, 06:23
Т.е. как я понимаю, пока имеет смысл только увеличить время цикла программы?

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

Паэлпапаэл
19.05.2015, 07:15
да у Вас там куча проблем,это видно по тому что показано на скринах,а что творится с остальным... и это еще не заглядывая в проекты
чередовать инпуты с оутпутами не совсем разумно, не оставляете шансов на групповые запросы
но начять нужно всёравно с самой сети

Тем не менее, пока что самое криминальное, что от вас услышал - так это использование "американских" адресов в программе)

capzap
19.05.2015, 07:49
Тем не менее, пока что самое криминальное, что от вас услышал - так это использование "американских" адресов в программе)

третий раз говорю, каковы пинги до всех устройств в вашей мети? Скрины выложите, тогда и можно начинать искать "криминал"


Открыл проект первого плк, элементарная проверка на неиспользуемые переменные выдала больше сотни "мусора", на множественную запись в конфигурацию не меньше выдало строк

Паэлпапаэл
19.05.2015, 16:22
А подскажите, что значит "множественная запись в конфигурацию"?

capzap
19.05.2015, 17:16
это значит нажать F11, после компиляции в меню выбрать проект->контроль->Множественная запись выхода и смотреть результат

taranur
20.05.2015, 13:14
это значит нажать F11, после компиляции в меню выбрать проект->контроль->Множественная запись выхода и смотреть результат

Ну и что, что множественная запись. Всё равно обновление выхода происходит один раз в конце цикла

Паэлпапаэл
26.05.2015, 10:07
Сделали опрос между ПЛК по RS485 (по Modbus RTU), проблемы с обрывами связи между самими ПЛК теперь не беспокоят, по крайней мере, пару суток с этим все нормально. Только остается опрос ПЛК от АРМов оператора. Здесь вот периодически появляются проблемы - связь прерывается, и восстанавливается сама либо через какой-то небольшой промежуток - 2-3 сек, либо обрывается на большее количество времени - вплоть до одного часа. Пинги сделаем до устройств от АРМа оператора.

Pans
08.06.2015, 09:01
У меня такая же проблема, я так понял, что какие-то аппаратные проблемы у самих ПЛК, тяжелый для них протокол TCP, скорее всего не хватает вычислительных мощностей, т.к. по RTU все работает отлично. Capzap`a можете не слушать, он тут в каждой теме отметился, но ни разу по делу ничего не сказал.

приборист
08.06.2015, 09:11
У меня такая же проблема, я так понял, что какие-то аппаратные проблемы у самих ПЛК, тяжелый для них протокол TCP, скорее всего не хватает вычислительных мощностей, т.к. по RTU все работает отлично. Capzap`a можете не слушать, он тут в каждой теме отметился, но ни разу по делу ничего не сказал.
;)
Capzap виноват, ага.
Может Драйвера надо править?