Неверные данные с COM порта

@Delegat · Регистрация: 13.04.2009

Author24 — интернет-сервис помощи студентам

Добрый день. Пишу ПО для работы с автовесами. Данные передаются через COM порт. У меня есть код для приема данных:

C#

        private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
        {
            int byteRecieved = serialPort1.BytesToRead;
            byte[] mBytes = new byte[byteRecieved];
 
            serialPort1.Read(mBytes, 0, byteRecieved);
 
            string s = BitConverter.ToString(mBytes);
            Console.WriteLine(s);
        }

Байты бегут, значения их меняются при смене веса, НО!!! Приходят данные, отличные от того, что дано в документации.

Например я получаю с весов следующее:

C++

1 2	82-3A-81-A0-C5-B2-C1-B0-C1-B0-C1-8D- 82-3A-81-A0-C5-B2-C1-B0-C1-B0-C1-8D

А по документации начальный байт должен быть 0x2, а КС - 0xD. Здесь даже близко такого нет. В общем у меня приходят совершенно другие данные и вес я снять не могу. Более того, в документации размер пакета - 16, а у меня только 12.

Подскажите в чем может быть проблема?

PS. Данные текут непрерывным потоком.

@kolorotur · 10.07.2013, 15:39

Добрый день.
Перво-наперво сверьте с документацией параметры порта, которые вы выставляете в своем приложении: Baud Rate, Parity, Stop Bits, Data Bits и т.д.
В 90% случаев кривые данные приходят из-за несовпадения параметров порта на девайсе и контроллере.

@Spectral-Owl · 10.07.2013, 16:19

не хочу наговаривать на класс SerialPort, но его событие DataReceived не всегда срабатывает на полный ответ, т.е. ответ иногда разбивается на 2 ответа. (хотя может у меня такие девайсы попадаются)

в общем как избавлялся от этой проблемы:
читал в отдельном потоке по 1 байту с порта (беспрерывно)
после прочтения определённого байта проверял не конец-ли это посылки (по протоколу девайса и проверкам контрольной суммы)
если конец то обнулял буфер, вызывал событие.

если наступил тайм-аут, а посылка ещё не пришла: или событие отсуствия ответа (если буфер совсем пуст), либо события ошибочного CRC (если есть хоть байт).

если нужно могу код скинуть.

@kolorotur · 10.07.2013, 16:48

Сообщение от Spectral-Owl

его событие DataReceived не всегда срабатывает на полный ответ, т.е. ответ иногда разбивается на 2 ответа.

Совершенно верно. Срабатывание события зависит от свойства ReceivedBytesThreshold. Если там поставить 1, то событие будет срабатывать как только придет первый байт сообщения.
Если используется протокол с всегда фиксированной длиной сообщений, то это значение можно просто выставить на длину сообщения и в обработчике считывать сообщение целиком.

А так — да, надо считывать кусками.

@kolorotur 17790 / 12941 / 3381 Регистрация: 17.09.2011 Сообщений: 21,215
	10.07.2013, 15:39	2
	Добрый день. Перво-наперво сверьте с документацией параметры порта, которые вы выставляете в своем приложении: Baud Rate, Parity, Stop Bits, Data Bits и т.д. В 90% случаев кривые данные приходят из-за несовпадения параметров порта на девайсе и контроллере. 0

@Spectral-Owl 608 / 583 / 157 Регистрация: 29.06.2010 Сообщений: 1,620
	10.07.2013, 16:19	3
	не хочу наговаривать на класс SerialPort, но его событие DataReceived не всегда срабатывает на полный ответ, т.е. ответ иногда разбивается на 2 ответа. (хотя может у меня такие девайсы попадаются) в общем как избавлялся от этой проблемы: читал в отдельном потоке по 1 байту с порта (беспрерывно) после прочтения определённого байта проверял не конец-ли это посылки (по протоколу девайса и проверкам контрольной суммы) если конец то обнулял буфер, вызывал событие. если наступил тайм-аут, а посылка ещё не пришла: или событие отсуствия ответа (если буфер совсем пуст), либо события ошибочного CRC (если есть хоть байт). если нужно могу код скинуть. 0

@kolorotur 17790 / 12941 / 3381 Регистрация: 17.09.2011 Сообщений: 21,215
	10.07.2013, 16:48	4
	Сообщение от Spectral-Owl его событие DataReceived не всегда срабатывает на полный ответ, т.е. ответ иногда разбивается на 2 ответа. Совершенно верно. Срабатывание события зависит от свойства ReceivedBytesThreshold. Если там поставить 1, то событие будет срабатывать как только придет первый байт сообщения. Если используется протокол с всегда фиксированной длиной сообщений, то это значение можно просто выставить на длину сообщения и в обработчике считывать сообщение целиком. А так — да, надо считывать кусками. 1