Какая CRC правильная

[vladh]

Могу еще выложить рабочую модель в Протеусе. Там один контроллер передает периодически обсуждаемый код, а другой принимает и выводит эти данные на экра ЖКИ. Здесь все нормально.

[DmitriyVDN]

01,03,01,01,00,03,55,F7 ????
Нет, так тоже не получилось

Да вот пожалуйста. Если вы в этом языке хорошо разбираетесь.

не знаю что у вас не получается, вот выдрал из кода функцию подсчета CRC
вместе с массивом отправляемым по модбасу

[vladh]

не знаю что у вас не получается, вот выдрал из кода функцию подсчета CRC
вместе с массивом отправляемым по модбасу

Я имел в виду, что CRC подсчитана верно, только не всегда понятно какой байт переедается первым старший или младший. Так во я пробовал пересылать и так и так, ПЧ не отвечает! Реально я контролирую ответные посылки на выводе 1 микросхемы U3. Роль ПЧ в модели играет U1. На основании модели я вижу, что данные пересылаются верно.

[DmitriyVDN]

На основании модели я вижу, что данные пересылаются верно.

В где верно? если CRC для вашей посылки должен быть F755 а у вас на сриншоте F555

[vladh]

В где верно? если CRC для вашей посылки должен быть F755 а у вас на сриншоте F555

Здесь я просто в коде Для U1 сделал раньше выводить младший байт, а затем старший. Простите я не заметил, что вводится F5, а надо F7. Сейчас поправлю

[vladh]

Сегодня посмотрел на свою плату и обратил внимание, что на ней не стоят резисторы, которые рекомендуют для этого интерфейса. Т.е. нет подтягивающих резисторов к цепи питания и цепи земли и нет терминаторного резистора, хотя на плате для них место предусмотрено. Но с другой стороны смущает то, что с кодом написанном на СИ все работает. Правда, надо сказать, что в моем случае линия связи короткая всего 20 см. Да, и еще меня смущает то, что нет связи программы Modbus Poll С ЧП. МОХА была до этого исправна.

[tsb]

Простите я не заметил, что вводится F5, а надо F7. Сейчас поправлю

А что ж это за формат индикации посылки на LCD такой "смешанный": "тело посылки" в десятичном коде, а CRC в HEX?

[tsb]

Все таки, пока вы не пошлете правильный пакет запроса, включая CRC, частотник вам не ответит. Тут уже писали, что в конце данной посылки должно быть 55 F7 (в HEX). Кроме того, у вас после передачи посылки вставлена задержка перед переключением на прием:

CRC.HighByte = 0xF5
CRC.LowByte =  0x55
HRSOut Ab, Kod_func, Registr.HighByte, Registr.LowByte, Kol_reg.HighByte, Kol_reg.LowByte 
HRSOut CRC.HighByte, CRC.LowByte 
DelayMS 12
PORTC.5 = 0       ' Разрешение на прием данных

12 мс - это слишком много. Частотник, теоретически, может начать передавать ответ через 4 мс после получения запроса. Длина ответа на данный запрос - 11 байт, что на скорости 9600 займет примерно 11 мс. Поэтому задержка переключения на прием в 12 мс запросто может "обрезать" начало ответа от частотника. Я думаю, в этом месте задержка вообще не нужна (ну, в крайнем случае, не более 1 мс).

Но с другой стороны смущает то, что с кодом написанном на СИ все работает.

Так почему бы не использовать тот, работающий код?

[DmitriyVDN]

Частотник, теоретически, может начать передавать ответ через 4 мс после получения запроса. Я думаю, в этом месте задержка вообще не нужна (ну, в крайнем случае, не более 1 мс).

а практически мастер должен сразу переключится на прием и слушать в линии "тишину" в течении 4мс и в случаи ее нарушения поднять флаг колизии на линии, дождаться "тишины" и по флагу повторить запрос.

[jump]

насчет коллизий, таймаутов и т.д. - смотрим руководство по модбас и на ППЧ - часто оговаривается минимальный таймаут между запросами, он намного больше, чем стандартный на 3,5 символа. кстати. однажды налетел на риф - вместо заводской уставки поставил минимальную по ДШ ППЧ и... инвертор замолк... совсем. только через пару часов техподдержка прояснила ситуацию после отсылки ей файла конфигурации
еще раз: в случае с ТС - оптимальным было б прослушать шину Uport 1150 и терминалом от чужой прошивки