А по таймауту длительностью в полтора байта при передаче ответа никак? И кстати, вы должны знать, сколько слов в ответе, начало ответа по перввым двум байтам элементарно определяется.
А по таймауту длительностью в полтора байта при передаче ответа никак? И кстати, вы должны знать, сколько слов в ответе, начало ответа по перввым двум байтам элементарно определяется.
Пробовал с временными фокусами. Все равно информация в строке сдвинута. Если предварительно посчитать количествоСообщение от VaBo
байтов ответа,могу поймать последний байт,но не могу же я для каждой команды это просчитывать.
По адресу устройства находите равный ему первый байт, по первому байту находите команду и длину посылки, по ней находите CRC, если CRC совпало - всё вычислено правильно, иначе ищете другой первый байт.
Поясняю боллее конкретно. Выдаю команду 10 03 01 00 00 01 86 АС В ответ должен получить 10 03 02 80 00 25 0Е
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта .Если бы ответ приходил по декону или овну,проблем бы никаких не было,т.к
у них в конце пакета служебный символ 0D. Отслеживая входной поток по этому признаку конца я извлекаю данные из
буфера,этим самым очищаю его. С модбасом такой фокус не проходит. Ваши рекомендации справедливы в том случае,если бы адрес ,который Вы советуете отлавливать и от него плясать,стоял последним в сообщении,а не первым.
Если я последую Вашему совету и по приходу адреса,буду читать буфер, то кроме байта с этим адресом там ничего не
будет.
Решений типа обработать пришедшую строку,те ее упорядочить-не предлагать.Это я сам
знаю.
Последний раз редактировалось Одесса; 14.09.2018 в 08:21.
Разве такое возможно?
Байты с прибора Овен приходят в правильной последовательности. Но я сторонним прибором их отловить не могу,так не знаю от чего синхронизироваться.
Вам надо понять, где что в буфере? Начало пакета в этом примере 10 03 (или при ошибке 10 83) Непонятно, чем знание конца полезнее знания начала.
Программными средствами я могу контролировать любой байт залетающий в буфер. Допустим могу отловить 1 адресный байт
и по этому событию могу прочитать буфер. Но толку от этого не будет,потому что буфер будет пуст,так туда ещё ничего не успело
залететь. Если бы этот адресный байт был последним,то я бы отловив этот байт ,и по этому событию прочитав буфер, увидил бы
Все данные,где последним был бы адресный байт.
Все проблему решил костылем. Обработал принятую строку следующим образом. Нашел в строке адресный байт и его индекс.
путем перебора. Не очень сложными программными манипуляциями вырезал адресный байт с байтами следующими за ним до
конца строки. И поставил этот байтовый блок в начало строки. Понимаю,что это не лучший метод решения,но лучшего не знаю.
Спасибо тему закрываю.
А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?
Ваши права
