Диагностика устройства на шине RS485

Вид для печати

14.04.2016, 15:52
Dima_31

Диагностика устройства на шине RS485

Добрый день!
В моем проекте СПК110 подключен по RS485 к 3-м модулям 32ДН и одному 8Р. Подключаю не через драйверы Овен а через Modbus_Master_com. Подскажите, где можно найти диагностику.
Мне необходимо знать, какое устройство отвалилось (например - нет питания), если такое произошло.
14.04.2016, 16:01
Евгений Кислов

Вложений: 1

Цитата:

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

Добрый день!
В моем проекте СПК110 подключен по RS485 к 3-м модулям 32ДН и одному 8Р. Подключаю не через драйверы Овен а через Modbus_Master_com. Подскажите, где можно найти диагностику.
Мне необходимо знать, какое устройство отвалилось (например - нет питания), если такое произошло.

Можно вот так, например:

Вложение 23897
14.04.2016, 16:20
Dima_31

Спасибо! Понятно!
16.04.2016, 08:08
Dima_31

Дальше по теме возник новый вопрос.
У меня задача - однозначно отделить случайный сбой от "полного финиша". В CDS 2.3 я вел посдсчет сбоев, при превышении порога выводил состояние ошибки. Запуск общения по RS485 производил по триггеру.
Здесь не понятно, как ведет себя переменная .xError при восстановлении связи.
Если запускать общение по триггеру, как узнать, что обмен состоялся - для разрешения начала обмена со следующим модулем?
Может есть готовые решения?
16.04.2016, 09:35
Евгений Кислов

Цитата:

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

Дальше по теме возник новый вопрос.
У меня задача - однозначно отделить случайный сбой от "полного финиша". В CDS 2.3 я вел посдсчет сбоев, при превышении порога выводил состояние ошибки. Запуск общения по RS485 производил по триггеру.
Здесь не понятно, как ведет себя переменная .xError при восстановлении связи.
Если запускать общение по триггеру, как узнать, что обмен состоялся - для разрешения начала обмена со следующим модулем?
Может есть готовые решения?

Мастер в случае отсутствия ответа делает несколько попыток обращения к слэйву, если ответ все же придет, то xError должна сброситься.

У вас есть четкая уверенность, что необходима именно такая реализация? Потому что в случае конфигурирования Modbus средствами CODESYS, по идее, пользователь не должен брать на себя такие вопросы. Modbus Master не будет вечно стучаться к погибшему слэйву, а спустя пару попыток перейдет к следующему - это готовый компонент, не подразумевающий дополнительной обвязки.
16.04.2016, 11:09
Dima_31

Требования заказчика - наличие самодиагностики системы. В случае отказа одного из модулей я должен его определить и дать сообщение оператору.
16.04.2016, 12:06
Евгений Кислов

Цитата:

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

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

Тогда, может, контролировать xError по таймеру? Если в течение, например, минуты он находится в TRUE, тогда генерируем сообщение для оператора об отказе модуля.
16.04.2016, 20:43
Dima_31

Я тоже подумал об этом. Наверное, так и сделаю.
24.05.2016, 07:26
Dima_31

Проверил диагностику системы в лаборатории. Пока все работает как планировалось. Время контроля по таймеру - 4 секунды.
27.05.2016, 07:18
Евгений Кислов

Цитата:

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

А можно поподробнее, как войти в окошко справа, не найду такого у себя.

Окошко справа - это просто код программы на языке ST. Достаточно вбить там имя Modbus компонента из дерева проекта (которое слева) и поставить точку - появится выпадающий список переменных компонента. В редакторе CFC все будет аналогично.