Доброго времени суток товарищи "Форумчане",

Прошу помощи советом, идеей, замечанием ошибки, наставлением .

Несколько станков управляются локально контроллерами Delta DVP EX2. Интерфейс с Оператором на каждом станке реализован посредством HMI (Weintek).

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

Реализация задачи выполнена путем использовать свободного порта COM3 каждого ПЛК с общую MODBUS RTU и организации обмена в OPC - Master Universal OPC (ИНСАТ).

Схема построения сети привожу ниже:
Для обращения к интересующим регистрам ПЛК использую имеющуюся в DELTA Address MAP

Нажмите для просмотра прикрепленного файла



Суть проблемы: после подключения по COM3 2ой и более ПЛК OPC-сервер перестает видеть переменные проекта, к которым обращается:
Нажмите для просмотра прикрепленного файла

C одним ПЛК все работает замечательно:
Нажмите для просмотра прикрепленного файла

Уверен, что проблема в чем-то очевидном, вот только в чем понять пока не могу.

Буду очень признателен за полезную мысль в решении данной задачи.

Еще раз, на всякий случай:
система один ПЛК - OPC (по COM3) работает стабильно. (при этом панель по COM1 также функционирует штатно).
Как только подключаю второй ПЛК система два ПЛК - OPC перестает работать . (при этом панель по COM1 для каждого ПЛК продолжает функционирует штатно).

Ниже выкладываю скриншоты настройки протокола в ПЛК, а также OPC - сервере

Настрйока протокола в ПЛК:
Нажмите для просмотра прикрепленного файла

Настройка протокола в OPC:
Нажмите для просмотра прикрепленного файла

Задание адреса:
Нажмите для просмотра прикрепленного файла

Обращение к регистру данных ПЛК из OPC:
Нажмите для просмотра прикрепленного файла

..по верхам
скорость 115200, да еще для соединения звездой с неизвестной общей длиной линии, не айс, 19200 или даже 9600
межсимвольный таймаут 0 мс, тоже скользкая настройка, может влиять на поведение slave в ModBus RTU в зависимости от реализации
повторы пи ошибке еще ладно, но повторное соединение после ошибки 10 сек!!! жесть!, если оно так и работает
макс допуст разрыв адресов в запросе чтения, не совсем ясно что это, вернее как оно влияет, это типа если большой разрыв то 2 запроса шлет или как

..ну так, навскидку

Добрый день!

А каким образом к ПК подключается сеть DVP?
Преобразователь USB-RS485? Настройки преобразователя смотрели, если это так?

Или напрямую к СОМ-порту подключали?

И приведите физическую реализацию сети - неужели действительно RS485 сделали звездой, да ещё на большие расстояния, да ещё с 115200?

Прежде всего определите отсутствие проблем с физической стороны:
1. Настроенный ОРС, с Ваших слов, может работать только с одним ПЛК, а при опросе всех сразу не работает. Верно ли понимаю, что физически все ПЛК висят на шине данных, а в ОРС модно выбрать любой из 4-х ПЛК и опрос по нему ведется нормально? Если Да, то проверьте все ли ПЛК имеют разные адреса. Конфигурация ОПС может быть составлена верно, но не соответствовать настройкам в самих ПЛК
2. Если НЕТ, то перво-наперво проверить наличие терминаторов на обоих концах сети (120 Ом)
3. Как вариант добавить в ОРС-конфигурацию паузу на ожидание ответа от слейва - в сети Мастер-слейв слушают все, а отвечает тот, кому адресован запрос.
4. Также обратить внимание, а точно ли RTU режим на ПЛК, поскольку у ПЛК АSCII режим при обмене с панелями

Судя по мануалу производителя для коммуникационных возможностей контроллеру не хватает ресурсов процессора или исполнительной среды. Поэтому по портам COM1-COM3 в мануале сплошные ограничения. Полезно параллельно на порт подвесить USB-RS485 преобразователь и посмотреть логи обмена через терминал при работе в группе в различных конфигурациях, а так же снять осциллограммы на различных скоростях. Порой все зависит не от скорости обмена, а от быстродействия системного ПО контроллер.
Сам месяц назад занимался разбором полетов одного именитого контроллера с приводами AUMA. Выяснил что контроллер ошибочно отрабатывает ответы привода если они приходят раньше 2 мс после последнего символа в запросе. "Тормозил" ответы привода AUMA с использованием преобразователя RS232/RS485 ADAM4520 (имеет встроенный буфер) и контроллер начинал нормально работать.

Кстати, в мануале COM3 только режим ASCII, а у Вас RTU в схеме.
Нажмите для просмотра прикрепленного файла

Здравствуйте ktulu,

Вы правы, я неточно отразил схему соединения: конечно же ПЛК соединены между собой последовательно.
Расстояние между двумя соседними ПЛК примерно 5-6 метра.

В остальном попробую завтра днем изменить параметры, на которые Вы указали:
1. уменьшу скорость до 19200;
2. Повторное соединение снижу до 3 сек (в принципе, со стороны OPC можно быстро попробовать разные настройки. Поиграюсь от 1 до 3 сек).
Благодарю за советы.

Здравствуйте ogorsv,

Вы правы, DVP подключаю в ПК через преобразователь интерфейса USB-RS485. Преобразователь работает надежно - использую его более 5ти лет в работе с разными ПЛК (все проблемы, связанные с драйверами при переходе на Winwows10 решены.

Прошу прощения за неточное представление сети. ПЛК связаны между собой последовательно. Расстояние между двумя соседними ПЛК не более 5метров по кабелю (оборудование установлено рядом друг с другом.
Относительно сети - да, поставил 115200. Раз настройки позволяют зачем отказываться? (это из серии моих рассуждений). Уменьшу скорость до 19200. Попробую. О результатах напишу. Спасибо за совет.

Здравствуйте Chabol,

Да, Вы верно понимаете: все ПЛК висят на одной шине - витая пара, RS485. Каждому ПЛК присвоен свой адрес (от 1 до 4) и в OPC сервере я вижу каждый ПЛК по отдельности. Но как только пытаюсь подключить любые два - связь прекращается (возможно термин неточный, но суть в том , что переменные приобретают обозначение BAD) и обмена данными больше нет.

Протокол обмена по COM3 специально для каждого ПЛК специально "перезаливал" лично, чтобы удостовериться в правильности установки протокола - представлено выше на скиншоте. Разница программы в ПЛК только в номере адреса: от 1 до 4.

Терминатор не стал ставить - расстояние между началом и концом сети физически 20 метров (не 1200). Проблема сохраняется даже если оставить только 2 ПЛК в сети и физически отключить витую пару от 3 и 4 ого () т.е. пробовал схему ПК+ПЛК1+ПЛК2 - всего 6 метров.

Добавить ожидание ответа от Slave - спасибо за рекомендацию. Попробую добавить завтра, напишу о результатах.

Относительно RTU - режима. Да, он установлен принудительно (показано на скриншоте) Реле M1320 - SET - устанавливает RTU режим. На OPC "Использовать режим ASCII" - ложь.

Спасибо за состоятельное отношение к моей проблеме.
Обязательно попробую последовательно все высказанные рекомендации.

Здравствуйте wild,

Спасибо за рекомендацию. Проверю в режиме ASCII на скорости 19200 и 38400.

Добрый день!
Обратите внимание на рекомендации Delta (см.рис)
Нажмите для просмотра прикрепленного файла
Подобное Вашему поведение встречалось как раз при двухпроводном подключении. Подключение третьего провода исправило ситуацию.
Да, и терминаторами никогда не пренебрегал. Независимо от расстояний.
С уважением,
СВ

Доброго времени суток, уважаемые Форумчане!

Благодарю ktulu, ogorsv, Chabol и wild за оказанную помощь в решение моей задачи

Система заработала.

Причина возникновения ошибки (не буду посыпать голову пеплом, по вашим улыбкам и так будет все понятно) - дублирование адресов двух смежных ПЛК (отдельное спасибо Chabol). После фиксации - OPC увидел все ПЛК и обмен данными начал выполняться.

Также я выполнил несколько тестов: работа с разной скоростью обмена, режимами RTU/ASCII, а также проверил работу с использованием еще одной HMI (OMRON) - вместо OPC сервера (на ПК).
Результаты следующие:

Если в качестве мастера на COM3 выступает OPC сервер (ПК), то сеть стабильно работает и на 19200 и на 38400 и на 115200 как в ASCII, так и RTU.

Если в качестве мастера на COM3 выступает HMI (панель Оператора, у меня под рукой оказалась OMRON NB7W-TW00B) то сеть стабильно работает на разных скоростях (проверял до 115200) только в режиме ASCII. Видимо об этом и сказано в мануале Delta (отдельное спасибо wild).

Также еще раз хочу поблагодарить ogorsv. Вы указали на момент, с которым действительно не каждый день встречаешься и вряд ли на него сразу обратишь внимание. Терминаторы мне приходилось ставить на своей практике пока только два раза . В обоих случаях это было как раз из-за практически предельно-допустимого расстояния сети RS-485 (без установки репитера).

С уважением,
GYL