Время ожидания или Timeout

[manjey73]

да я переключил на 1080 качество, по умолчанию почему-то было в 720 и все размыто…

[JurasskPark]

Проблема в одном — я не могу победить свой мозг, что так работает и так можно делать. Вот хоть убейте не могу переубедить, что два Read будут помогать.

Логику я понимаю.
Взял из массива нужный номер массива, получил информацию о том, сколько нужно получить еще данных. Опять читаешь через Read этот массив. Если размер массива весь, то хорошо. Если нет, то ждем дальше.

Не знаю. Я просто слишком долго возился с этим, что мне кажется, что код долго работает и я не могу себя переубедить в этом обратно. Мозг хочет готовое решение, которое работает быстро и как во Read не ждать Timeout, а отправить STOP слово. 😀

[manjey73]

сделайте в коде Session в начале

Stopwatch stopwatch = Stopwatch.StartNew();

и в конце Session

            stopwatch.Stop();
            Log.WriteLine(Locale.IsRussian ?
                "Получено за {0} мс" :
                "Received in {0} ms", stopwatch.ElapsedMilliseconds);
            FinishSession();

так вы реальное время узнаете.

и по вашему видео мне стало непонятно… Выше по тексту из описания протокола байт >0x80 говорящий об ошибке вроде должен быть [1] а у вас на видео почему-то проверка [9] ???

А вроде как если [1] не 0х80 то [2] длина Прочитав 3-ри первых байта вы определяете сколько дочитать, начиная с [3] до конца либо ошибки, либо нужное количество + 2 байта CRC. [3] в данном случае смещение вкуда продолжить чтение.
зная, сколько прочитать все само остановится без всякого таймаута.
Таймаут в данном случае будет действовать только на обрыв связи или отсутствие связи. То есть вы определили, что дочитать надо еще 75 байт, произошел обрыв связи на 50-м байте, вот тут и сработает таймаут, так как будет ожидать чтение еще 25-ти байт. Если все байты пришли, то стоп и так будет, так как вы задали чтение определенного количества байт вторым кодом чтения, после определения сколько байт дочитать.

[Mikhail]

Проблема в одном — я не могу победить свой мозг, что так работает и так можно делать. Вот хоть убейте не могу переубедить, что два Read будут помогать.

Попробуйте для сравнения использовать вместо предоставляемого Connection свой TcpClient. Получится ли с ним реализовать чтение иначе?

[JurasskPark]

Попробуйте для сравнения использовать вместо предоставляемого Connection свой TcpClient. Получится ли с ним реализовать чтение иначе?

Вот пример кода. Синхронное чтение. Да, на одном компе, но по сети в поле тоже пробовал — там тоже работает.
https://www.youtube.com/watch?v=ojCkRUDDbfk

P.S. Исправил ошибку. Поставил условие

if (!mSocket.Connected)
{
    return (byte[])null;
}

[Mikhail]

Какой вывод можно сделать из данного видео?

[JurasskPark]

Что сколько клиент показал пришло данных, столько он и отдаст и больше ждать нет смысла. 😀

[manjey73]

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

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

[manjey73]

если не прав, поправьте.

Вы подключаетесь как TCP клиент к устройству Ethernet к которому подключен по RS485 прибор ?

отключите прибор и посмотрите что произойдет.
то, что у вас есть readTimeout для TCP клиента не относится к Timeout непосредственно в линии RS485, он может быть настроен в самом TCP сервере…

[Mikhail]

Что сколько клиент показал пришло данных, столько он и отдаст и больше ждать нет смысла.

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

[Автор]

Записи