- В этой теме 26 ответов, 2 участника, последнее обновление 3 месяца, 2 недели назад сделано
.
-
Сообщения
-
Модель преобразователя Orange Pi с подключенным COM портом и поднятым пакетом socat 🙂
Не может в буфере остаться данных, это нонсенс… Устройство с последовательным портом, работает в режиме запрос — ответ и никак иначе.
Раз прибор ответил, значит к нему запрос пришел без искажений с правильной CS.
Если бы в буфере оставались данные, то он вернулся бы без искажений, каким был в прошлый раз.Канал связи разрывает соединение, если сеанс неудачный.
Почему при работе через COM порт не происходит разрыва соединения и некорректных данных ? все так же используется LastResponseOK = false
Скажите лучше, что запустить в VisualStudio в отладку, чтобы можно было устанавливать точки останова и проверить поведение буфера в режиме работы COM порта через TCP клиент ?
Ну не нормально такое поведение
Почему при работе через COM порт не происходит разрыва соединения и некорректных данных ?
Потому что это каналы связи разного типа, которые реализованы по-разному. Для COM-порта разрыв соединения в случае проблем не имеет практического смысла.
Скажите лучше, что запустить в VisualStudio в отладку
Работа портов или TCP-клиентов реализована на уровне ОС, поэтому вряд ли её получится отладить. Отладить обычным способом можно получение данных драйвером.
Было бы полезно найти Moxa NPort и попробовать запустить то же самое на ней для сравнения.Ну нет у меня Moxa NPort
Где тогда поправить код, чтобы убрать разрыв соединения по LastResponseOk = false ?
Это ведь явно в коде Scada заложено?
Вот простой пример, когда данный функционал вреден. Опрос прибора последовательным набором команд (Меркурий, Энергомера и подобные).
Например 3 запроса, на втором происходит таймаут на ответ по каким-то причинам, скажем задержка в сети, особенно если опрос происходит через интернет.
Я перевожу в невалидное состояние только те переменные, которые были в этом опросе.
Следующий опрос идет в рамках сессии без ошибок.
Зачем в данной ситуации разрывать соединение по TCP ?Если логикой требуется именно разорвать соединение, значит требуется дополнительная команда, которую пропишем вместе с LastResponseOK а не одной командой выполняем все действия…
При чем это происходит вроде только в том случае, если установлен параметр «Опрос после команды». Если выключить, то и проблем нет, кроме разрыва и соединения связи.
Пример еще банальнее. Пользователь ввел неправильный код команды, который отсутствует в драйвере. Сообщать об ошибке ввода команды CommPhrases.InvalidCommand и при этом выставлять LastResponseOK ? Где здесь логика тогда ?
Убедительные аргументы.
Попробуйте обновление.Супер, работает как должно работать 🙂
Вчера немного соврал. TCP клиент у драйвера MBus был через Raspberry Pi3 B+
Сейчас вот регистратор Пульсар как раз через Orange Pi
Но поведение было абсолютно одинаковым, если по каким то причинам команда не принимается, соответственно в коде LastResponseOK остается false и следующий запрос идет с нарушением буфера.Буду наблюдать дальше в процессе портирования драйвера Пульсар.
Михаил, просто что-то выключили в базовом драйвере канала ?
Не добавляли специальной команды для разрыва соединения если потребуется?
Например организация счетчика по выбранному условию и «алга» на перезапуск 🙂 ?Замечательно, что помогло. Не ожидал такого влияния разрыва связи.
Там добавилась опция, разрывать ли связь в случае ошибки сеанса связи. То есть можно включить как раньше было, если потребуется.Добавлю, что в случае ошибки сеанса опроса, TCP-клиент вычитывает все имеющиеся данные из буфера. Это, я думаю, будет полезно в любом случае.
Заметил тут вчера что ошибки с искаженным буфером все же пролетают.
Ну по крайней мере сразу после команды их уже нет.
Один из приборов (счетчик с MBus) стоит на опросе в цикле. На 69,5 тысяч опросов 23 ошибки. И вероятно именно с искажением буфера TCP клиента, других предпосылок вроде не было.Интересно, что может происходить в сети, все подключено у одному роутеру, что может приводить к ошибке…
- Вы должны авторизироваться для ответа в этой теме.