CODESYS V3.5. Настройка обмена с другими устройствами (Modbus, ОВЕН, OPC и др.)

[Евгений Кислов]

Добрый день.

Суть проблемы, как только в линии одну из устройств перестает отвечать, падает вся линия, блок OCL.TCP_Client не показывает никаких ошибок, блок OCL.MB_TcpRequest выдает SLAVE_DEVICE_FAILURE. При этом в сниффере МКОН видно как идет опрос линии. Если вернуть выпавшее устройство в строй, то после переинициализации OCL.TCP_Client (сброс и установка xEnable) ошибка пропадает и опрос снова идет корректно. В каком направлении искать ошибку?

Выложите, пожалуйста, простейший проект с опросом двух слэйвов через МКОН, на котором я смогу воспроизвести проблему (чтобы при физическом отключении одного слэйва опрос второго прекращался).

[knoppix]

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

Архив проекта во вложении, повторить на двух устройствах проблему не удалось, на шести устройствах проблема возникает достаточно часто, вынес в проекте опрос устройств в 100мс задачу, вроде стало постабильнее, но проблема все равно сохраняется, просто проявляется чуть реже. Сейчас протестировал еще одну линию с устройствами другого типа, опрос шел хорошо до появления в опросе не существующего устройства, потом вся линия ушла в SLAVE_DEVICE_FAILURE, поднял время задачи до 200мс, проблема осталась но стала проявляться чуть реже, то есть не на первом, а на втором-третьем устройстве которое не удалось прочесть.

[Евгений Кислов]

Архив проекта во вложении, повторить на двух устройствах проблему не удалось, на шести устройствах проблема возникает достаточно часто, вынес в проекте опрос устройств в 100мс задачу, вроде стало постабильнее, но проблема все равно сохраняется, просто проявляется чуть реже. Сейчас протестировал еще одну линию с устройствами другого типа, опрос шел хорошо до появления в опросе не существующего устройства, потом вся линия ушла в SLAVE_DEVICE_FAILURE, поднял время задачи до 200мс, проблема осталась но стала проявляться чуть реже, то есть не на первом, а на втором-третьем устройстве которое не удалось прочесть.

Спасибо за проект. Попробуем воспроизвести проблему у себя.

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

Уточните интервалы времени, пожалуйста.

[knoppix]

На 6 устройствах и 100мс, отвал одного из устройств приводит к отвалу всей линии в одном случае из десятка, при 20мс, всегда. И чем больше устройств тем больше вероятность что все посыплется.

[Votrj1]

Что то не нашел. Обмен СПК107 и ПР200 , 128 регистров, что то на запись, что то на чтение. Работает. Захотелось передачу со стороны спк некоторых переменных сделать почаще. Увеличил циклы всех не главных переменных в конфигураторе до 1000мс, а нужные оставил 100. Ничего не поменялось, часто менять переменные не получается, захлебывается. Поменял те которые установил на 1000 на работу по тригеру, стало естественно лучше. Вопрос почему не работает классическим путем. Такое впечатление что настройки цикла переменных не на что не влияют. На всяк работает можбас мастер спк всегда в цикле main 2. Цикл майн 10млс, ожид 1000, фрейм 50. Не понял вообщем.

[Евгений Кислов]

На 6 устройствах и 100мс, отвал одного из устройств приводит к отвалу всей линии в одном случае из десятка, при 20мс, всегда. И чем больше устройств тем больше вероятность что все посыплется.

Мы воспроизвели описанную вами проблему. Она проявляется при сочетании многих отдельных факторов, и одним из них является использование библиотеки OwenCommunication.
В вашей ситуации я рекомендую настроить обмен через стандартные компоненты Modbus в дереве проекта - в таком случае мы проблему не наблюдали.

[knoppix]

Мы воспроизвели описанную вами проблему. Она проявляется при сочетании многих отдельных факторов, и одним из них является использование библиотеки OwenCommunication.
В вашей ситуации я рекомендую настроить обмен через стандартные компоненты Modbus в дереве проекта - в таком случае мы проблему не наблюдали.

Понял, спасибо. Подскажите, пожалуйста, использование стандартных компонентов не будет конфликтовать с OwenCommunication, она так же используется для опроса RTU устройств, и для работы ПЛК в качестве Slave устройства через (OCL.MB_TcpSlave)?

[Евгений Кислов]

Понял, спасибо. Подскажите, пожалуйста, использование стандартных компонентов не будет конфликтовать с OwenCommunication, она так же используется для опроса RTU устройств, и для работы ПЛК в качестве Slave устройства через (OCL.MB_TcpSlave)?

Нет, не будет.

[knoppix]

Мы воспроизвели описанную вами проблему. Она проявляется при сочетании многих отдельных факторов, и одним из них является использование библиотеки OwenCommunication.
В вашей ситуации я рекомендую настроить обмен через стандартные компоненты Modbus в дереве проекта - в таком случае мы проблему не наблюдали.

Еще два вопроса:
1. Замена МКОН на другое устройство не поможет?
2. Что делать если на линии больше 32 устройств (стандартные компоненты Modbus в дереве проектов не поддерживают больше 32 устройств)? Присутствуют линии до 45 устройств, разбить их на под линии уже нет физической возможности.

[Евгений Кислов]

Еще два вопроса:
1. Замена МКОН на другое устройство не поможет?
2. Что делать если на линии больше 32 устройств (стандартные компоненты Modbus в дереве проектов не поддерживают больше 32 устройств)? Присутствуют линии до 45 устройств, разбить их на под линии уже нет физической возможности.

1. Я не проводил тест с другим конвертером RTU/TCP - и, к сожалению, сейчас нет возможности это сделать.
2. Я проверю в понедельник, не сняли ли это ограничение в свежей версии плагина Modbus. Но даже если оно осталось - то МКОН поддерживает 2 одновременных TCP-подключения.
Так что можете добавить в дереве два Modbus_TCP_Slave для одного МКОН.