- В этой теме 69 ответов, 3 участника, последнее обновление 1 год, 1 месяц назад сделано
.
-
Сообщения
-
У вас нельзя рассчитать длину ответа в зависимости от запроса?
Я не углублялся сильно в протокол, но наверняка можно посчитать длину ответа.Когда я столкнулся разной длиной ответа, Михаил писал, что Timeout используется от штатной функции системы, он там есть и убрать его никак. Отсюда и вариант проверки на конечный байт был + Михаил тогда доработал механизм, что можно для остановки использовать массив байт.
Ну или брать сейчас для 6-й версии CnlBasic и сделать его аналог. Если ни одного байта не поступило, то сработает обычный Timeout, если поступил хоть один байт, то Timeout уменьшить до времени поступления например 2-3-х символов.
NЧ – количество часов;
NЧ = 24 – для всех суток, кроме текущих;
(включая текущий час)
Ну все у вас можно посчитать, до запроса должна быть логика, которая посчитает длину ответа. А так же можно выполнять проверку по 3-му байту фактически поступающим данным и расчетным.
Я примерным образом считал длину ответа в драйвере Пульсар, зная запрос, выставлял длину ответа в зависимости от количества байт параметра для данного запроса.
Соответственно Timeout работал только при отсутствии и обрыве связи. В остальных случаях принималось требуемое количество байт.Собственно у вас примерно так.
Читаете первые 3 байта, проверяете по 2-му байту что прибор не ответил форматом ответа об ошибке, если прибор говорит что это ошибочный запрос дочитываете 3 байта и разбираете ошибку.
Если нормальный ответ, то по 3-му байту считаете длину ответа + CRC и дочитываете, а потом разбираетесь соответствует ли количество в ответе требуемой длине согласно запроса.Ну тут три варианта:
1) Михаил добавит в CnlBasic ещё один вариант чтения и я буду доволен как слон 🙂
2) Я использую свой CnlBasic и только с ним драйвер булет работать.
3) Я отказываюсь и в драйвере реализую чтение через свои драйвера.P.S. Я не вижу большой сложности и проблемы, почему бы Михаил отказался реализовать ещё один вариант чтения данных, когда 4 штуки уже есть. 🙂
Если я правильно понял, то вызываются штатные функции по работе с COM портом.
Тут либо реализовывать свой аналог работы с портом, в котором убирать Timeout вообще и измерять длительность паузы после каждого принятого байта. Кстати это можно реализовать даже внутри драйвера, читая по одному байту. И потом склеивать весь ответ для логирования… Никто же не мешает.
Но в вашем случае все длины просчитываются если смотреть по протоколу, который не Modbus. Так что не вижу каких то проблем реализации на штатном драйвере канала.
Забавно, но сейчас вы рассуждаете так же как и я тогда, когда столкнулся с плавающей длиной ответа.
Вот смотрите, при приеме по одному байту что есть timeout? пауза на прослушку длины когда байты уже перестали приниматься? а теперь посмотрим на ситуацию с другой стороны, у вас должен быть пакет 256 байт и произошел обрыв связи когда 100 байт уже передались — это конец пакета или все же полноценный timeout ? 🙂
Есть запрос данных с таймаутом. Чтобы запрос завершился раньше окончания таймаута, должно быть выполнено какое либо условие.
В данный момент эти условия:
1. Достигнута заданная длина ответа.
2. Получен признак окончания пакета.Какой дополнительный вариант завершения запроса Вы хотите предложить?
Читаете первые 3 байта, проверяете по 2-му байту что прибор не ответил форматом ответа об ошибке, если прибор говорит что это ошибочный запрос дочитываете 3 байта и разбираете ошибку.
Если нормальный ответ, то по 3-му байту считаете длину ответа + CRC и дочитываете, а потом разбираетесь соответствует ли количество в ответе требуемой длине согласно запроса.Да, так обычно и делается.
Какой дополнительный вариант завершения запроса Вы хотите предложить?
Без условия указания количества получаемых байт.
/// <summary> /// Reads data. /// </summary> public override int Read(byte[] buffer, int offset, int timeout, ProtocolFormat format, out string logText) { try { int readCnt = 0; NetStream.ReadTimeout = timeout; // timeout is not maintained if all available data has been read Stopwatch stopwatch = Stopwatch.StartNew(); while (readCnt == 0 && stopwatch.ElapsedMilliseconds <= timeout) { // read data try { if (NetStream.DataAvailable) // checking DataAvailable is critical on Linux readCnt += NetStream.Read(buffer, offset, buffer.Length); } catch (IOException) { } } logText = BuildReadLogText(buffer, offset, readCnt, format); if (readCnt > 0) { logText = BuildReadLogText(buffer, offset, readCnt, format); UpdateActivityTime(); } return readCnt; } catch (Exception ex) { throw new ScadaException(CommPhrases.ReadDataError + ": " + ex.Message, ex);Я бы понимал, когда отдаем buffer[] размером 1000 байт, отдаем int count (количество получаемых данных), то в ответе у нас buffer[] размером count.
Но там нигде Array.Resize(ref buffer, readCnt) не делается…
- Вы должны авторизироваться для ответа в этой теме.