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

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

  • В этой теме 26 ответов, 2 участника, последнее обновление 1 год назад сделано Mikhail.
Просмотр 15 сообщений - с 1 по 15 (из 27 всего)
  • Автор
    Сообщения
  • #28730
    manjey73
    Участник

    Если отключить опрос после команды, то все в норме

    2023-05-29 16:19:45 Команда устройству [4] MBus Electro
    Выполнение команды setaddr
    Отправка (12): 68 06 06 68 53 FE 51 01 7A 01 1E 16
    Получено за 1010 мс
    
    2023-05-29 16:19:46 Отключение от ::ffff:192.168.0.9
    
    2023-05-29 16:20:00 Соединение с 192.168.0.9:4001
    
    2023-05-29 16:20:00 Сеанс связи с устройством [4] MBus Electro
    Отправка (9): 68 03 03 68 73 01 B1 25 16
    Приём (4/4): 68 90 90 68
    Приём (146/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 13 31 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0A FD 3A 00 10 0A FD 3A 00 10 0A FD 3A 00 00 0A FD 3A 00 00 0A FD 3A 04 50 1E 16
    OK!
    Отправка (5): 10 7B 01 7C 16
    Приём (4/4): 68 5D 5D 68
    Приём (95/95): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0C 04 27 14 01 00 0C 04 27 14 01 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C FD 3A 67 17 00 00 0C FD 3A 60 15 00 00 0C FD 3A 06 02 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 4A 16
    OK!
    Получено за 2006 мс
    

    Если же оставлять опрос после команды то происходит искажение буфера при команде, на которую не получено ответа.

    2023-05-29 16:23:02 Команда устройству [4] MBus Electro
    Выполнение команды setaddr
    Отправка (12): 68 06 06 68 53 FE 51 01 7A 01 1E 16
    Получено за 1012 мс
    
    2023-05-29 16:23:03 Отключение от ::ffff:192.168.0.9
    
    2023-05-29 16:23:03 Соединение с 192.168.0.9:4001
    
    2023-05-29 16:23:03 Сеанс связи с устройством [4] MBus Electro
    Отправка (9): 68 03 03 68 53 01 B1 05 16
    Приём (4/4): 90 68 08 01
    Приём (106/106): 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 10 28 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B
    Ошибка: Bus Timeout [4] MBus Electro
    Отправка (5): 10 7B 01 7C 16
    Приём (4/4): FD 3A 00 00
    Приём (60/60): 00 0B FD 3A 00 00 00 0A FD 3A 00 10 0A FD 3A 00 10 0A FD 3A 00 00 0A FD 3A 00 00 0A FD 3A 00 50 0E 16 68 5D 5D 68 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0C 04 27 14 01 00 0C
    Ошибка: Bus Timeout [4] MBus Electro
    Получено за 1469 мс
    
    2023-05-29 16:23:04 Отключение от ::ffff:192.168.0.9
    

    Следующую сессию все становится в норме.
    Если же ответ получен, то такой ошибки нет, опрос идет корректно

    Выполнение команды setshort
    Отправка (5): 10 40 01 41 16
    Приём (1/1): E5
    Получено за 44 мс
    
    2023-05-29 16:27:56 Сеанс связи с устройством [4] MBus Electro
    Отправка (9): 68 03 03 68 73 01 B1 25 16
    Приём (4/4): 68 90 90 68
    Приём (146/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 31 30 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0A FD 3A 00 10 0A FD 3A 00 10 0A FD 3A 00 00 0A FD 3A 00 00 0A FD 3A 03 50 3A 16
    OK!
    Отправка (5): 10 7B 01 7C 16
    Приём (4/4): 68 5D 5D 68
    Приём (95/95): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0C 04 27 14 01 00 0C 04 27 14 01 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C FD 3A 67 17 00 00 0C FD 3A 60 15 00 00 0C FD 3A 06 02 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 4A 16
    OK!
    Получено за 1966 мс
    

    Вопрос почему при отсутствии ответа и срабатывании таймаута на ответ, очередной запрос валится с ошибкой ?

    #28731
    manjey73
    Участник

    для Connection.Read сделал входной буфер на ответ, отличный от входного буфера Session. Результата не дало, все так же ломается ответ повторного запроса после команды.

    Пробовал делать Thread.Sleep после ответа на команду, так же результата не дало.

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

    Есть во всем этом что-то знакомое по части использования COM поверх TCP
    Сейчас так и работает через TCP клиент…

    #28735
    manjey73
    Участник

    В общем интересный момент. Если поставить точку останова в Session где-нибудь в начале. И после отправки команды, которая приводит к ошибке очередного чтения просто подождать немного, а потом нажать в отладке «Продолжить» ошибка НЕ ВОЗНИКАЕТ..

    Предположительно после отправки команды не успевает очиститься входной буфер и идет мусор…
    Хотя именно для проверки исполнения команды специально создал другой буфер, который к чтению в Session не имеет никакого отношения…

    То есть копать надо где-то в Connection.Read предположительно…

    #28736
    manjey73
    Участник

    Здесь задана неверная команда, происходит отключение канала связи и следом происходит ошибка

    2023-05-29 23:00:44 Команда устройству [4] MBus Electro
    Ошибка: команда с кодом setshortr не найдена
    Получено за 0 мс
    
    2023-05-29 23:00:44 Отключение от ::ffff:192.168.0.9
    
    2023-05-29 23:00:44 Соединение с 192.168.0.9:4001
    
    2023-05-29 23:00:44 Сеанс связи с устройством [4] MBus Electro
    Отправка (9): 68 03 03 68 73 01 B1 25 16
    Приём (4/4): 90 68 01 72
    Приём (106/106): 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 03 25 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD
    Ошибка: Bus Timeout [4] MBus Electro
    Получено за 971 мс
    

    А здесь команда отрабатывает как положено, LastRequestOK = true; и разрыва связи не происходит, следующий опрос после команды проходит корректно…

    2023-05-29 23:01:04 Команда устройству [4] MBus Electro
    Выполнение команды setshort
    Отправка (5): 10 40 01 41 16
    Приём (1/1): E5
    OK
    Получено за 47 мс
    
    2023-05-29 23:01:04 Сеанс связи с устройством [4] MBus Electro
    Отправка (9): 68 03 03 68 73 01 B1 25 16
    Приём (4/4): 68 90 90 68
    Приём (146/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 93 24 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B 2A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0B FD 3A 00 00 00 0A FD 3A 00 10 0A FD 3A 00 10 0A FD 3A 00 00 0A FD 3A 00 00 0A FD 3A 03 50 90 16
    OK!
    Получено за 1160 мс
    #28737
    manjey73
    Участник

    При LastRequestOK = false который выставляю при ошибке в команде приводит к разрыву соединения и последующей ошибке опроса после команды.

    2023-05-29 23:07:34 Отключение от ::ffff:192.168.0.9

    2023-05-29 23:07:34 Соединение с 192.168.0.9:4001

    Если в коде поставить во всех ошибках LastRequestOK = true, то опрос после команды идет без ошибки. Но ессно счетчик на некорректную команду не отрабатывает…

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

    На команду setaddr согласно описанию протокола ответ отсутствует?

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

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

    Если опрос происходит через преобразователь Ethernet-RS485, то нормально ли работает напрямую по COM-порту?

    #28744
    manjey73
    Участник

    Напрямую к COM порту не подключал, вечером попробую, прибор за стенкой висит 🙂

    Забавно, восстановление буфера может произойти по нажатию Пауза в окне Журнала линии связи. Это вообще прикольно 🙂 Пока не нажмешь, будет сыпать ошибками из-за неверного буфера приема…

    #28745
    manjey73
    Участник

    13:20:21 Команда устройству [4] MBus Electro
    Ошибка

    13:22:59 — Нормализация

    Со временем связь нормализуется, если стоит период опроса от 1-й секунды нормализация происходит через запрос как правило, иногда через два, если больше установлено времени то обычно через запрос всегда.

    #28746
    manjey73
    Участник

    Учитывая, что в коде Session массив буфера всегда определен как
    buf_in = new byte[4]; для заголовка и
    Connection.Read — чтение заголовка
    buf_in_res = new byte[buf_in[1] + 2];
    Connection.Read — чтение тела запроса + контрольная сумма

    Очень становится интересно, почему буфер при появлении ошибки (LastRequestOK = false), разрыва соединения и его подключения не очищается…

    Ну или Connection.Read начинает проглатывать байты после такой комбинации

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

    1

    При работе напрямую через COM порт никаких нареканий.
    Мне кажется что с TCP клиентом какие-то глюки все же…
    Как выше писал, если в коде Session буфер всегда новый, то откуда берется мусор и потеря байт ?

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

    Вот с утра пришла мысль, а почему LastResponseOk = false является триггером на разрыв TCP соединения вообще? Это вроде не его задача вовсе…

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

    Забавно, восстановление буфера может произойти по нажатию Пауза в окне Журнала линии связи.

    Коммуникатор не знает о том, нажата ли пауза в Администраторе или нет.

    Очень становится интересно, почему буфер при появлении ошибки (LastRequestOK = false), разрыва соединения и его подключения не очищается…

    Каждое соединение имеет свой внутренний буфер. Следовательно, может быть, где-то в преобразователи остаются данные.

    Какая модель преобразователя Ethernet-RS-485?

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

    Вот с утра пришла мысль, а почему LastResponseOk = false является триггером на разрыв TCP соединения вообще?

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

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