Прошу совета

[Одесса]

VaBo товарищ CRC считает в онлайн калькуляторе, ему впадлу написать 10 строк кода, чтобы она считалась сама по себе....

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

Поправка - не обработав один ответ посылает очередной запрос...

Мелки Вам неоднократно делали замечания по поводу Вашей невнимательности. Если Вы и дальше будете делать выводы
космических масштабов не вникнув в суть вопроса это вызовет не только недоумение но даже смех. У меня есть предположение
что это даже не невнимательность,а элементарная лень прочитать до конца пост и вникнуть в суть проблемы. В этом ответе я легко
и аргументированно докажу правоту вышеизложенных слов . И в каждом другом посте сделаю то же самое.
1. Отвечаю на 1 абзц Вашего ответа. Товарищу не впадлу написать 10 строк кода по вычислению СRC. Товарищ написал этот совет
не программистам,а слесарям-киповцам,для которых слово CRC является матерным ругательством и которым я посоветовал использовать калькулятор для его вычисления.
2. По второму вопросу насчёт датского королевства. В каком конкретно предложении и какого поста вы видили ,чтобы я посылал
запрос к устройству не дождавшись ответа по первому запросу? Вы сами родили такое предположение. И в в своей нелепой
фантазии обвиняете меня.

[melky]

Одесса тогда простой вопрос - почему у вас ответ начинается не с 1-ого байта а идет мешанина ?
Найдете ответ на этот вопрос - найдете и решение получать данные с 1-ого байта.

Еще раз говорю, любой прибор слейв в сети Modbus не будет ничего передавать, если не проверит что запрос предназначен ему и он не битый.
Никаких смещений в буфере ответа быть не должно в принципе.

Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта

Это говорит о том, что прибор отвечал несколько раз (было несколько запросов) и вы ловите куски различных ответов в буфере... найдите причину почему

[Одесса]

Одесса синхронизироваться необходимо от окончания запроса. в RTU слейв устройство не отвечает когда попало, а только после определения, что запрос прислан именно ему и что CRC запроса соответствует пакету. иначе слейв просто промолчит.
Послали запрос - ждите ответа.
з.ы. мне что-то кажется, что вы в многопоточном режиме даже опрос прибора сделали в STM, а это неправильно.

Отвечаю опять же аргумментированно.
1.Я не обращаюсь к кому попало с неправильной контрольной суммой команды. Если бы я. так сделал ,как Вы предполагаете,то
Ваши предположения верны. Но они не верны. Устройство отвечает. О чем написано в первых постах,которых Вы не читали. Если
бы читали, первого предложения в этом посте не было бы.
2. Комментировать то,что Вам кажется ни есть аргументом для специалиста. Ни в каком многопоточность режиме я не работаю,
это я для того ,чтоб Вам не казалось.

[melky]

Одесса я и не говорил, что вы обращаетесь к кому попало, я только сказал, что вы обращаетесь явно более одного раза до окончания ответа и его обработки.
По этому у вас в буфере и идет скользящие ответы.
Повесьте на порт ПК с наблюдателем порта и сами посмотрите что у вас с запросами и что с ответами, ну и скрин программы сюда выложите, потому что интересно.

Ну и шаманов с бубнами тут нет, чтобы на словах понять, что вы там за код накодили...

Я вот на ПК принимаю с порта 100-150 байт и мне как-то в голову не приходит искать какой-то там байт, я просто беру весь полученный буфер за минусом CRC, считаю CRC и сверяю с CRC, присланным прибором - ВСЕ, что я делаю не так ?
Отсюда вопрос, почему у вас буфер не с 1-ого байта ответа а скользящий ?

[Одесса]

Одесса тогда простой вопрос - почему у вас ответ начинается не с 1-ого байта а идет мешанина ?
Найдете ответ на этот вопрос - найдете и решение получать данные с 1-ого байта.

Еще раз говорю, любой прибор слейв в сети Modbus не будет ничего передавать, если не проверит что запрос предназначен ему и он не битый.
Никаких смещений в буфере ответа быть не должно в принципе.

Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта

Это говорит о том, что прибор отвечал несколько раз (было несколько запросов) и вы ловите куски различных ответов в буфере... найдите причину почему

Мелки. Жаль что синусоида Вашего биологического жизненного ритма ,а именно интеллектуальная кривая находится сейчас
даже не на нулевом уровне ,а в глубоком минусе. Отвечаю почему. Вы мне советуете ответить на вопрос самому себе именно на
тот вопрос,который я задал на форуме. Вопрос к Вам - нафига мне задавать вопрос на форуме,если я по Вашему совету должен
отвечать на него сам.
На Ваши рассуждения о том,что никаких смещений в буфере не должно быть в принципе,я с Вами вполне согласен.
Но я не знаю где у содержимого буфера начало. И если я не зная этого вытаскиваю содержимое буфера с произвольного буферного
индекса ,принимая его за начало,то после этого все остальные байты буфера строятся за этим ,как бы началом. И за этого и получается ,что содержимое буфера ,вытянутое мной появляется в таком непристойном виде.
Чтоб Вам было более понято,пока Ваша синусоида не выйдет на нужный уровень, объясняю. Если по протоколу
DCON или Овен последним байтом в в ответе является байт OD, то у модбаса такой фишки нет. И с этими протоколами у меня нет
проблем. Отслеживая входные данные по этим протоколам,я ориентируюсь на этот байт,по приходу которого извлекаю содержимое буфера, тем самым его опорожняя. У модбаса такого конечного байта нет. Поэтому я и задал вопрос на форуме. На
мой вопрос Вы ответили,что я дятел,который CRC считает на калькуляторе и что я не дружу с датским королевством и что бы
Я сам отвечал на свой вопрос,заданный мной на форуме.
Спасибо вам за Ваш обстоятельный ответ.

[melky]

Одесса поиском конечного байта в протоколе Овен или DCON в скользящем буфере вы сделали костыль, при помощи которого вы получаете ответы от приборов.
Найдите первопричину и у вас отпадет необходимость в костыле.

Я пока еще не изучал STM, мне еще это только предстоит, но ваша проблема именно в том, что вы изначально неправильно работаете с портом при опросе приборов.

Скрин с программы снифера будет ? без него все вами вышесказанное ни о чем...
Опять же, код программы опроса тоже не помешал бы, тут и Сишники наверняка бродят.

А вообще вам больше какой-то профильный форум по STM даст больше толку...

[Одесса]

Одесса я и не говорил, что вы обращаетесь к кому попало, я только сказал, что вы обращаетесь явно более одного раза до окончания ответа и его обработки.
По этому у вас в буфере и идет скользящие ответы.
Повесьте на порт ПК с наблюдателем порта и сами посмотрите что у вас с запросами и что с ответами, ну и скрин программы сюда выложите, потому что интересно.

Ну и шаманов с бубнами тут нет, чтобы на словах понять, что вы там за код накодили...

Я вот на ПК принимаю с порта 100-150 байт и мне как-то в голову не приходит искать какой-то там байт, я просто беру весь полученный буфер за минусом CRC, считаю CRC и сверяю с CRC, присланным прибором - ВСЕ, что я делаю не так ?
Отсюда вопрос, почему у вас буфер не с 1-ого байта ответа а скользящий ?

Ничего Вы там не вытаскиваете. За Вас это делает СОМ Ская утилита,которая следит за входным буфером,а Ваше дело отследить в программе ,когда Вам эта утилита скажет,что данные в буфере готовы- мол забирайте товарищ. Поэтому Вам так и
легко отбросить CRC и всех деллов. И как эта утилита положила эти данные в буфер ,это проблемы утилиты. Я же эти данные вы
таскиваю сам,как ота утилита.

[melky]

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

ВДУМАЙТЕСЬ в эту последовательность.

У вас на STM есть возможность использовать дискретный вход ? сделайте подпрограмму запроса только по импульсу включения входа а не в цикле и посмотрите что у вас получится.

[Одесса]

Одесса поиском конечного байта в протоколе Овен или DCON в скользящем буфере вы сделали костыль, при помощи которого вы получаете ответы от приборов.
Найдите первопричину и у вас отпадет необходимость в костыле.

Я пока еще не изучал STM, мне еще это только предстоит, но ваша проблема именно в том, что вы изначально неправильно работаете с портом при опросе приборов.

Скрин с программы снифера будет ? без него все вами вышесказанное ни о чем...
Опять же, код программы опроса тоже не помешал бы, тут и Сишники наверняка бродят.

А вообще вам больше какой-то профильный форум по STM даст больше толку...

Если бы я был грубым человеком,то ответил бы,что сам ты костыль,но так как я человек воспитанный,то так не отвечу-солдт
ребенка не обидит. Где ты там костыль увидил? Как мне по другому бескостыльному методу принять ответ по деконовскому
протоколу? Ответь пожалуйста. Буду безмерно благодарен. Спецов профильного форума сопряжение приборов Овен с STM мало
волнует. Насчёт кода программы. У STM стандартное решение UART приемника,как в любом процессоре.В программном плане
я должен указать размер буфера и все. По заполнению буфера возникает прерывание основной программы и я должен в подпрограмме прерывания вытянуть эти данные. Но я не знаю сколько байт мне должно прийти и поэтому размер буфера указываю приблизительно,что неправильно. Также прерывание можно сделать по любому байта. Пробовал и то и другое.
Задавая вопрос на форуме-готового решения не получил. На форуме по STM задавать не буду,там у меня самого спрашивают.
Поэтому тему закрываю. Возьму свою абракадабру с буфера, найду в нем адрес,поставлю его первым и к нему приклею все остальное. Вот это называется костыли,а не то о чем говорите Вы. Это называется ещё решил проблему через жопу. Иногда и такое
приходится делать .
Вопрос закрыт.

[Одесса]

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

ВДУМАЙТЕСЬ в эту последовательность.

У вас на STM есть возможность использовать дискретный вход ? сделайте подпрограмму запроса только по импульсу включения входа а не в цикле и посмотрите что у вас получится.

Если бы я делал запрос два раза, то в ответе получил бы повторяющиеся байты. А я получаю полноценный ответ ,со всеми байтами
и правильной контрольной суммой,но порядок последовательности байтов неправильный.