Странности поведения линии связи

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

Просмотр 6 сообщений - с 16 по 21 (из 21 всего)
  • Автор
    Сообщения
  • #12171
    MikhailMikhail
    Модератор

    В случае же получения байт ответа должен сбрасываться по истечении паузы «тишины» после принятия последнего байта ответа.

    Изучение вопроса показало, что в .NET можно установить таймаут только на всю операцию чтения. Таймаут меджу приёмом соседних байт отсутствует, к сожалению. Для сравнения в Delphi такая возможность была. Но Delphi скорее мёртв, чем жив. Хотя есть как минимам одна российская скада, написанная на Delphi ))

    #12172
    MikhailMikhail
    Модератор

    Таймаут меджу приёмом соседних байт можно реализовать программно.

    #12173
    manjey73
    Участник

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

    прибор отправляет пачку байт с учетом промежутка между ними, когда прибор все отправил возникает тишина, прибор ждет следующего запроса. а сейчас получается, что мы задали буфер 200 байт и даже если прибор ответил количеством 10 байт (ну не понравилось ему что-то в запросе) мы ждем пока придут все 200. и только тогда сбросится тайм аут…
    Речь именно о наличии поступления байт и последующей тишине, сброс таймаута только в этом случае. Если мы ничего не получаем, то как положено ожидаем весь период таймаута.
    Такой режим в Коммуникаторе можно реализовать в текущем исполнении или требуется доработка ?

    #12174
    MikhailMikhail
    Модератор

    Таймаут между байтами — это и есть прекращение приёма при наступлении тишины определённой длительности.

    Такой режим в Коммуникаторе можно реализовать в текущем исполнении или требуется доработка ?

    Требуется доработка канала связи Serial Port. Причём для каналов связи TCP и UDP эта функция вообще не будет работать, потому что там приходит сразу пакет.
    Поэтому самый оптимальный вариант — определять длину, которую требуется принять. Либо, если протокол позволяет — прекращать приём по символу окончания пакета.

    #12175
    manjey73
    Участник

    Хм, что-то я не заметил прекращения таймаута по наступлению тишины, когда счетчик с M-Bus подключал. Очень медленное чтение. Теперь понимаю почему, ожидались все 250 байт. Подключение было USB — M-Bus, через COM порт.

    А в режиме работы порта поверх TCP вообще работать не будет я так понимаю ?

    #12176
    MikhailMikhail
    Модератор

    я не заметил прекращения таймаута по наступлению тишины

    Его нет. Я писал о том, что можно реализовать, но лучше вычислять ожидаемую длину получаемых данных.

    А в режиме работы порта поверх TCP вообще работать не будет я так понимаю ?

    Верно, в TCP нет подобного таймаута, т.к. данные приходят пакетами, а не побайтно.

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