Ошибка при запросе после команды

Стартовая страница Форумы Ошибки в работе Ошибки Коммуникатора Ошибка при запросе после команды

Просмотр 12 сообщений - с 16 по 27 (из 27 всего)
  • Автор
    Сообщения
  • #28754
    manjey73
    Участник

    Модель преобразователя Orange Pi с подключенным COM портом и поднятым пакетом socat 🙂

    Не может в буфере остаться данных, это нонсенс… Устройство с последовательным портом, работает в режиме запрос — ответ и никак иначе.

    Раз прибор ответил, значит к нему запрос пришел без искажений с правильной CS.
    Если бы в буфере оставались данные, то он вернулся бы без искажений, каким был в прошлый раз.

    Канал связи разрывает соединение, если сеанс неудачный.

    Почему при работе через COM порт не происходит разрыва соединения и некорректных данных ? все так же используется LastResponseOK = false

    #28755
    manjey73
    Участник

    Скажите лучше, что запустить в VisualStudio в отладку, чтобы можно было устанавливать точки останова и проверить поведение буфера в режиме работы COM порта через TCP клиент ?

    Ну не нормально такое поведение

    #28756
    Mikhail
    Модератор

    Почему при работе через COM порт не происходит разрыва соединения и некорректных данных ?

    Потому что это каналы связи разного типа, которые реализованы по-разному. Для COM-порта разрыв соединения в случае проблем не имеет практического смысла.

    Скажите лучше, что запустить в VisualStudio в отладку

    Работа портов или TCP-клиентов реализована на уровне ОС, поэтому вряд ли её получится отладить. Отладить обычным способом можно получение данных драйвером.
    Было бы полезно найти Moxa NPort и попробовать запустить то же самое на ней для сравнения.

    #28757
    manjey73
    Участник

    Ну нет у меня Moxa NPort

    Где тогда поправить код, чтобы убрать разрыв соединения по LastResponseOk = false ?

    Это ведь явно в коде Scada заложено?

    Вот простой пример, когда данный функционал вреден. Опрос прибора последовательным набором команд (Меркурий, Энергомера и подобные).
    Например 3 запроса, на втором происходит таймаут на ответ по каким-то причинам, скажем задержка в сети, особенно если опрос происходит через интернет.
    Я перевожу в невалидное состояние только те переменные, которые были в этом опросе.
    Следующий опрос идет в рамках сессии без ошибок.
    Зачем в данной ситуации разрывать соединение по TCP ?

    Если логикой требуется именно разорвать соединение, значит требуется дополнительная команда, которую пропишем вместе с LastResponseOK а не одной командой выполняем все действия…

    При чем это происходит вроде только в том случае, если установлен параметр «Опрос после команды». Если выключить, то и проблем нет, кроме разрыва и соединения связи.

    • Этот ответ был изменен 1 год, 1 месяц назад от manjey73.
    #28759
    manjey73
    Участник

    Пример еще банальнее. Пользователь ввел неправильный код команды, который отсутствует в драйвере. Сообщать об ошибке ввода команды CommPhrases.InvalidCommand и при этом выставлять LastResponseOK ? Где здесь логика тогда ?

    #28762
    Mikhail
    Модератор

    Убедительные аргументы.
    Попробуйте обновление.

    #28763
    manjey73
    Участник

    До изменения

    После изменения

    Супер, работает как должно работать 🙂
    Вчера немного соврал. TCP клиент у драйвера MBus был через Raspberry Pi3 B+
    Сейчас вот регистратор Пульсар как раз через Orange Pi
    Но поведение было абсолютно одинаковым, если по каким то причинам команда не принимается, соответственно в коде LastResponseOK остается false и следующий запрос идет с нарушением буфера.

    Буду наблюдать дальше в процессе портирования драйвера Пульсар.

    #28764
    manjey73
    Участник

    Михаил, просто что-то выключили в базовом драйвере канала ?
    Не добавляли специальной команды для разрыва соединения если потребуется?
    Например организация счетчика по выбранному условию и «алга» на перезапуск 🙂 ?

    #28773
    Mikhail
    Модератор

    Замечательно, что помогло. Не ожидал такого влияния разрыва связи.
    Там добавилась опция, разрывать ли связь в случае ошибки сеанса связи. То есть можно включить как раньше было, если потребуется.

    #28776
    Mikhail
    Модератор

    Добавлю, что в случае ошибки сеанса опроса, TCP-клиент вычитывает все имеющиеся данные из буфера. Это, я думаю, будет полезно в любом случае.

    #28780
    manjey73
    Участник

    Заметил тут вчера что ошибки с искаженным буфером все же пролетают.
    Ну по крайней мере сразу после команды их уже нет.
    Один из приборов (счетчик с MBus) стоит на опросе в цикле. На 69,5 тысяч опросов 23 ошибки. И вероятно именно с искажением буфера TCP клиента, других предпосылок вроде не было.

    Интересно, что может происходить в сети, все подключено у одному роутеру, что может приводить к ошибке…

    #28787
    Mikhail
    Модератор

    Может быть, просто данные приходят с задержкой иногда, и опрос сбивается.

Просмотр 12 сообщений - с 16 по 27 (из 27 всего)
  • Вы должны авторизироваться для ответа в этой теме.