Ошибки таймаута? Или неправильные запросы?
На первые по идее и реакция не нужна.
Ошибки таймаута? Или неправильные запросы?
На первые по идее и реакция не нужна.
Мне нужно знать что устройство отвалилось и в обмене более не участвует. ПЛК110 соответственно отдавал не нулевой статус операции обмена. А сейчас любая операция обмена с МКОН по Ethernet проходит успешно, даже если подключенное к нему по RS485 устройство не ответило.Сообщение от melky
Если скорость реакции не важна, то я делаю так: Считаю кол-во ошибочных запросов, если ПОДРЯД вернулось к примеру 5 ошибок, то значит связь отвалилась. Чем больше число тем вернее, но из практики вроде и до 3-х можно считать.
Я же написал выше, что обмен через МКОН не позволяет детектировать ошибку, обмен с МКОН всегда без ошибок, просто данные с подключенного по RS485 устройства не приходят и все.
Пардон, мимо прошел. Тогда может другой вариант?
Я так делал для слэйва, что бы он как-то знал что связь с мастером отвалилась и нужно что-то предпринять, в моем случае безопасно остановить выполнение алгоритма. Для этого мастер с периодичность раз в несколько секунд инвертирует сетевую переменную. Слэйв по каждой инверсии сбрасывает таймер, но если таймер досчитал до конца, значит связь оборвалась.
Да это единственный возможный вариант, но он возможен только для своих устройств. У меня же через МКОН подключены 4 частотника от Innovert, они ничего инвертировать не согласные
Может в частотнике есть какая-то не нужная переменная, которую можно записывать и считывать изменяя каждый раз? Хотя тут получается, что мы к МКОНу обращаемся и такой алгоритм может не прокатить. В новой версии есть прошивка для прозрачного режима, тогда бы это сработало. Но в прозрачном-то режиме и ошибка должна приходить по идее. Тут кроме разработчиков вряд ли кто поможет.Да это единственный возможный вариант, но он возможен только для своих устройств. У меня же через МКОН подключены 4 частотника от Innovert, они ничего инвертировать не согласные
Старые МКОНы на STM-ках вроде собраны, если руки дойдут может что своё туда напишу. По идее там сильно не придется реверс инжинирингом заниматься, узнать пины uarta, кнопки и светодиода, а Ethernet должен на стандартных пинах сидеть, как по даташиту.
Мне очень хороший способ подсказал пользователь EFrol применительно к панели СП307 к которой через МКОН сосисками подвязаны ПВТ110. Если в макросе организовать чтение регистра конкретного устройства через функцию Read, например Read(NET_0, 7, MODBUS_TCP_REG_4X, 1300, 0, TYPE_WORD, &Value621) и этой функцией читать какой-то регистр в нужном слэйве, то сама эта функция в качестве значения выдает TRUE/FALSE в зависимости от отклика конкретного слэйва (в примере с адресом 7). Таким образом просто присвоив значение этой функции подходящей переменной можно понимать, отзывается слэйв или нет. Нужно посмотреть кодэсис, наверняка там тоже можно реализовать нечто подобное. В случае СП307 и ПВТшки я так читал регистр 1300, который в одном из битов передает статус своей связи с зондом. Поскольку эти данные были мне тоже нужны, получилось 2 в одном. FLOAT32 с температурой и влажностью я читал по другому, чтобы не раздувать макросы. Но сама идея прикольная.
Не получится, в том и дело, что МКОН как буфер работает. Он сам опрашивает регистры и если связь отвалилась, то Вы об этом не узнаете, об этом знает только МКОН, но он не хочет об этом сообщать.
Последний раз редактировалось stesel; 05.12.2024 в 19:36.
Ничего он сам не опрашивает.
Ваши права
Ответить с цитированием