Не понятный ответ от Modbus RTU

[AVeshnik]

Здравствуйте. Работаю над соединением по Modbus RTU панельки Delta Tp70P и ЧП Danfoss FC 51. При подключении ЧП напрямую к компу все в порядке(На запрос приходит корректный ответ)

obminPLC-PCH.png

При соединении панельки как Master к компу Slave(на компе стоит Modbus Slave) тоже все нормально(ловлю общение программой FSPM)

obminPLC-PC.png

Но при стыковке частотника и панельки ответ не такой как надо и запись в регистр ЧП не происходит. Вижу это потому что подсоединил частотник к компьютеру через преобразователь интерфейсов и ловлю его ответы FSPM. Вот что он выдает

obmin.png

Помогите, пожалуйста, понять что означает 3F между частями ответа и что с ним сделать чтобы ответ стал человеческим. Спасибо.

[alex_ugrumov]

Похоже это какие-то поразиты,помехи или несоответствие настроек. И кстати 3F было ещё и в первом эксперименте. Один раз ПЧ (его же адрес 02) ответил нормально, а дальше повалилось. Так что похоже в нём дело. А расстояние какое? Как кабель проложен? ПЧ при работает на двигатель? Другие источники помех? Настройки (особенно число стопов) точно одинаковое?

[AVeshnik]

Расстояние где то около 10 см: стоит ноут, рядом лежит панелька, и ЧП. Подключаются экранированным проводом(не витая пара). Источник помех если бы был то он влиял бы и когда подключал панельку и ЧП напрямую к ноуту. А так какая то мистика получается. В первом эксперименте там где нормально- это напрямую с ноута, а там где понеслось это уже между панелькой и ЧП. Настройки одинаковые: 9600,N,8,1. Перепроверил много раз.

[alex_ugrumov]

ПЧ же стоит (не крутит двигатель)?
При таких условиях не должно быть проблем с помехами.
3F - это что-то не верно воспринятое из сети. Панелька запрашивает 02 03 ... А при прослушке видно 02 06... 06 - это 03 сдвинутое на один бит влево. Поэтому и предположение, что стоп биты как-будто разные. Или как будто тактовые частоты немного отличаются.
Почему 02 верно передаётся? Да потому что после паузы на линии, а дальше передача идёт без пауз и пошло расхождение, чем дальше там больше, вплоть до выделения несуществующего 3F.
Совет поставить
1) 9600,8,2,None, провести опыт
2) потом 9600,8,2,Odd, провести опыт
3) убедится, то все терминаторы отключены (их нет).
Такой ещё вопрос: вы когда эксперименты проводите (РС-куом опрашивая ПЧ и панелькой обращаясь к РС) мы же цепь не разбираете (все три абонента на ней остаются), так? И питание с неиспользуемого не снимаете, так?

[AVeshnik]

Не крутит. Сейчас просто провожу опыты и они вместе лежат.
По поводу цепи: разбираю и не разбираю. То есть пробую напрямую панелькой к ЧП подключится но запись не происходит. Тогда подключаю к ЧП еще преобразователь интерфейсов(что бы увидеть что отсылает частотник). А когда проверяю РС-ЧП и РС-панель, то они проверяются отдельно. То есть в момент проверки РС-ЧП панель отключена и от шины и от питания и когда проверяю РС-панель то ЧП отключен.

[megavolt86]

А разве не к определенному регистру надо обращаться?
Судя по скриншотам непонятно какой запрос отсылается и какие регистры принимаются.
Или для этих устройств какойто свой модбас?)
Если есть таблица регистров параметров частотника то к нужным регистрам просто обращаетесь с панели...не?)

[AVeshnik]

Сначала так и задумывалось но при подключении панельки напрямую к ЧП на панельке выводилось сообщение Communication Error. В тех поддержке сказали что это скорей всего потому что порт заточен на продукцию Дельта и посоветовали связь устанавливать при помощи ПЛК. О каком именно скриншоте вы говорите?

[megavolt86]

Вообще про скриншоты в первом посте.
А адресация и мастер\слейв правильно расставили?
Я со шайдером долго мучился, и адресации и скорости и четности все перепробовал, затем определил мастера и заработало)

[AVeshnik]

Я так понимаю что запросы может выдавать мастер. По скрину видно что идет запрос-ответ. Так я думаю что с этим все в порядке. Или я ошибаюсь?

[AVeshnik]

Совет поставить
1) 9600,8,2,None, провести опыт
2) потом 9600,8,2,Odd, провести опыт
3) убедится, то все терминаторы отключены (их нет).

Пробовал менять но ничего не дало. В обще в инструкции к ЧП написано что для Modbus RTU надо выбрать определенный параметр и когда я подключал ЧП к компу действительно только с ним связь и устанавливалась. Терминаторы вроде отключены раз напрямую к компу связь была.

[megavolt86]

Раз комп опрашивает частотник, тогда сделайте такие же настройки передачи в панели и экспериментируйте с адресацией .

[Alex question]

Я конечно не специалист в этих делах, но судя по скриншотам обмен по модбасу вообще не работает т.к. во всех скринах в ответ присылается какая то фигня.

Могу посоветовать для начала изменить запрос. В данный момент вы запрашиваете кучу регистров и в этом ответе очень сложно разобраться что же пошло не так. Может где то вылазит за адресное пространство. Может в адресном пространстве есть дырки. И т.д. и т.п.

Попробуйте считать третьей командой только один регистр и посмотреть что получится.
Ну и выложить скриншоты обмена.

Далее на всякий случай нужно убедиться, что устройство поддерживает третью команду. Потому что иногда бывает так что поддерживается только четвертая команда, а на третью шлются ошибки (и наоборот кстати).

Ну и разумеется проверьте правильность указания первого считываемого регистра в адресном пространстве. Нужно убедиться что этот адрес существует.

Далее с простой командой по чтению одного регистра уже можно будет играться всякими четностями, стоп битами и т.д. т.к. контрольную сумму из 6 байт посчитать проще, чем из запроса на полкилобайта.

[alex_ugrumov]

А разве не к определенному регистру надо обращаться?
Судя по скриншотам непонятно какой запрос отсылается и какие регистры принимаются.

С чего вы взяли? На первой картинке идёт запрос к устройству 0х02 по функции чтения 0х03 на чтение по адресу 0х071В регистров в количестве 1шт. Ответ - 0х0000.
На втором запрос к тому же устройству, той же функцией, регистр опять же 1шт, но по адресу 0х0000. Ответ нормальный. Что вам тут "непонятно"?

Или для этих устройств какойто свой модбас?)
Если есть таблица регистров параметров частотника то к нужным регистрам просто обращаетесь с панели...не?)

Обычный вполне. Таблица вообще не важна пока. Проблемы на канальном уровне.
Вы бы хоть немного вникли, прежде чем первое, что в голову пришло, писать.

Я конечно не специалист в этих делах,

Так и не пишите

Могу посоветовать для начала изменить запрос. В данный момент вы запрашиваете кучу регистров и в этом ответе очень сложно разобраться что же пошло не так. Может где то вылазит за адресное пространство.

Откуда вы это взяли? Запрашивается ОДИН регистр по функции 0х03. Вникнете хоть немного, прежде чем писать.

Далее на всякий случай нужно убедиться, что устройство поддерживает третью команду. Потому что иногда бывает так что поддерживается только четвертая команда, а на третью шлются ошибки (и наоборот кстати).

Поддерживает. См. рисунок 1 и комментарий к нему (над рисунком. первое же предложение ТС)

Андрей Васильевич, давайте подведём некоторые итоги и зафиксируем, что имеем. Я перечислю ряд утверждений и экспериментов. Подтвердите их или опровергните. Пожалуйста, каждое в отдельности. Пункты ниже. А пока я опишу, в чём я считаю проблема. И почему нужно провести описанные ниже эксперименты. Проблема точно на уровне RS485 (интерфейса), не на уровне протокола. Такое ощущение, что идёт рассогласование по частоте. Смотрите, когда идёт нормальный запрос, его начало - 02 03. В мусоре мы видим 02 06. Это значит, что второй байт сдвинулся на один бит. А потом вообще выделился несуществующий 0х3F. Почему 02 корректный? Потому что он идёт после паузы на линии и все устройства синхронизированы. Дальше по мере передаче это рассогласование в 1 бит на на дайте накапливается. Что мне не понятно, так это почему при запросу панель < - > РС, байты запроса выделяются корректно, а при работе панель < - > ПЧ тот же запрос распознаётся с мусором. Даже сквозь мусор видно, что ПЧ не вопринимает запрос и не отвечает на него, хотя от РС отвечал. Я думаю, что нужно более тщательно рассмотреть параметры передачи (скорость, битность, чётность). Либо это электрические проблемы и перекоммутация как-то влияет на сеть. Пункты ниже направлены именно на то, чтобы прояснить эти моменты.

Расскажу пока случай который у нас был с Модбасом совсем недавно. Обнаружили, что один из слейвов некорректно отвечает на запросы чтения, если в них запрашивается более (не помню точно, пусть будет какая то примерная цифра) 5 регистров. Стали выяснять. Оказать, что производители это слейва, AEG к слову, поставил кварц, тактирующий центральный микропроцессор на с базовой частотой RS, например, 8.192. А с округлённой, например, 10. И получилось, что частота при делении получается не точно, скажем 9600, а чуть другая. И это "чуть" накапливается и в итоге при продолжительной непрерывной передаче выливается в рассинхронизацию. Мы это обошли более короткими запросами. Но осадок остался и общая производительность шины упала. Это не ваш случай. У вас идут проблемы уже на втором байте. Но что-то похожее. Я думаю стопы или 7/8.


1) Сеть RS485, 2 провода. В неё подключены: панель (выступает Modbus мастером), ПЧ (всегда Modbus слейв с адресом 0х02), РС для проверки (в общем случае только слушает, в ряде экспериментов выступает мастером вместо панели). "+" всех 3-х устройств RS485 подключены вместе. "-" всех 3-х устройств RS485 подключены вместе.
2) на всех устройствах параметры передачи (скорость, битность, стоп и чётность) задаются непосредственно в настройках. Нет авто определения.
3) Расстояния сети небольшие, ПЧ не вращает двигателем, Влияние помех можно исключить.
4) Я рекомендую проводить эксперименты не перебирая цепь сети. Возможно подключая для прослушки РС вы как то нарушаете обмен. В теории подключение в режиме прослушки не должно влиять на сеть (ну, то есть конечно может, но не при таких расстояниях и скоростях). Я рекомендую, назначить ПЧ адрес 0х02 (как сейчас), а РС, когда он прикидывается слейвом 0х04, это позволит проводить эксперимент панель < - > РС без отключения ПЧ. Для проведения эксперимента РС < - > ПЧ, с исключением панели можно попробовать залить в неё проект без опроса какого-либо подчинённого (не уверен, что при этом панель не будет гадить в линию).
5) вы провели эксперимент: РС опрашивал ПЧ. Всё было впорядке, он отвечал. Это так?
Я прошу повторить эксперимент, следуя рекомендации п.3. И выложите, пожалуйста, результаты. Прошу запрашивать, как вы и делали ранее, один регистр, но по одному и тому ж адресу всегда (например, 0х0000), чтобы исключить разночтения. Плюс в этом случае CRC будет одно и та же это упростит разбор, когда пойдёт каша. Когда выкладываете принтскрин, путь там будет только этот экспериметн. Видите люди путаются, не заставляйте нас выцеплять крупицы результатов и объёмных картинок.
6) В проводили эксперимент: Панель опрашивала РС (он прикидывался слейвом). Всё было в порядке, РС отвечал. Это так?
Я прошу повторить эксперимент, следуя рекомендации п.3. И выложите, пожалуйста, результаты с учётом замечаний по п.4.
7) вы провели эксперимент: панель опрашивал ПЧ. РС в режиме прослушки линии. Тут панель сообщает, что связи нет. В прослушке видны какие-то постоянно появляющиеся 3F. Это так?
Я прошу повторить эксперимент, следуя рекомендации п.3. И выложите, пожалуйста, результаты с учётом замечаний по п.4.
8) вы пробовали менять формат передачи: количество стоп бит и чётность. Результаты по пп. 4,5,6 без изменений. Это так?. Выложите, пожалуйста, результаты "с мусором". Мусор по прежнему это 3F или другой. Он стоит в тех же местах или других? По прежнему запрос идёт 02 06, вместо 02 03? Нужны принт скрины результатов.
Уверены ли вы, что параметры передачи на всех трёх устройствах действительно меняются (некоторые устройства нужно перегрузить по питанию, чтобы они восприняли изменение параметров передачи по сети. Относительно этого нужно свериться с инструкцией. У ПЧ очень большой внутренний конденсатор. и полное его отключение нужно контролировать по лампе CHARGE)?
9) попробуйте, пожалуйста, изменить скорость на 19200 и 4800. И провести эксперименты по пп 4,5,6. Я думаю в одном из этих экспериментов, 3F, будет заменено на 7F или 1F. вопросы те же, что и в п. 7. Нужны принт скрины результатов.
10) попробуйте, пожалуйста, при скорости 9600 поставить параметры обмена 7,1,NONE и 7,2,NONЕ. Вопросы такие же как в п.7. Нужны принт скрины результатов.
11) при параметрах обмена 9600,8,1,NONE, проведите такой эксперимент. Пусть ПЧ будет слейв с адресом 0х02, а РС - слейвом 0х04. Путь панель опрашивает по функции 0х03 один регистр с ПЧ, и один с РС, оба по адресу 0х0000. Выложите пожалуйста принтскрин прослушки. Есть ли связь с панель < - > РС?
12) при параметрах обмена 9600,8,1,NONE, проведите такой эксперимент. Пусть ПЧ будет слейв с адресом 0х02, и РС - слейвом 0х02. Но ПЧ пока отключите по питанию. Запустите опрос и покажите нормальный обмен. Далее остановите эмулятор слейва на РС (прослушка продалжает работать) и получите "обрыв связи" на панели. Включите питание ПЧ: пошёл мусор? Потом переключите обратно.

Совет поставить
1) 9600,8,2,None, провести опыт
2) потом 9600,8,2,Odd, провести опыт
3) убедится, то все терминаторы отключены (их нет).

Пробовал менять но ничего не дало. В обще в инструкции к ЧП написано что для Modbus RTU надо выбрать определенный параметр и когда я подключал ЧП к компу действительно только с ним связь и устанавливалась.

Не очень понятно, что значит "ЧП написано что для Modbus RTU надо выбрать определенный параметр и когда я подключал ЧП к компу действительно только с ним связь и устанавливалась.". Поясните пожалуйста, о каких параметрах идёт речь?

[Jackson]

Сначала так и задумывалось но при подключении панельки напрямую к ЧП на панельке выводилось сообщение Communication Error. В тех поддержке сказали что это скорей всего потому что порт заточен на продукцию Дельта и посоветовали связь устанавливать при помощи ПЛК.

Круто. У Дельты какой то свой особенный модбас?

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

[AVeshnik]

Алексей Угрюмов, большое спасибо за детальное описание причин проблемы и путей ее решения. Приношу извинения за кучу мусора на скринах. Далее буду делать так чтобы было ясно к какому эксперименту что относится и каковы результаты. Самое первое что хочу сказать так это по поводу того скрина что вас ввел в заблуждения. Вам могло показаться что на 0х03 пришло 0х06. Но это не так. Это просто не очистил рабочую область после предыдущего эксперимента. То есть первым был запрос с РС на ПЧ 0х03. А второй это уже прослушка сети(я этой программой открываю порт для прослушки) но результаты предыдущего остались в окне программы. Такого больше не повторится.

И так по пунктам что вы описали:
1)На самом деле были разные махинации с подключением: с самого начала было 3 провода(еще земля). Земля была подключена к панельке но на ЧП ни к чему не подключалась. Вот тогда ничего на ПЧ не записалось и я начал искать причину и отсылать запросы отдельно и на ПЧ и с панельки на РС(думал что запросы разные идут с панельки и с РС на ПЧ). Но формат запросов был одинаковый. Потом я к ЧП параллельно подключил РС и начал слушать что приходит в ответ. И тогда я увидел что ответ разведен мусором. И подумал что это постоянная часть помехи и отсоединил РС от ЧП и начал экспериментировать с землей(отключил и от панели и от ЧП-результата нет; на панели-к земле, на ЧП-к земле-тоже ничего). И вот на выходных думал как еще землю подсоединить . Но после ваших слов мне кажется что это не помехи(плюс к этой мысли то, что кабель-экранированный).
2)Да. Настройки задаются непосредственно. Но на ПЧ их мало. И тут же хочется дать ответ на Ваш последний вопрос: если параметр ПЧ 8.33 оставить по умолчанию то связи не будет, а если поставить "2", то связь есть(хотя они одинаковые)

1.png

2.png

3.png

На контроллер панельки они задаются программно :

4.png

А вот окно для задания параметров на эмуляторе подчиненного:

5.png

3)Да, именно так.
4)Сделал.
5)Да. Вот результат:

PC-PCH.png

[alex_ugrumov]

Да вроде всё хорошо. Вроде везде 9600,8,1,None. На сколько я понял при выборе в ПЧ Modbus (8-30), по умолчанию скорость 19200(8-32). Вы вернули на 9600. Так?
Давайте тогда эксперимент 6 или даже сразу 11.

[AVeshnik]

6) Да. Вот результат

PLC-PC.png

7) Да именно. Вот запросы ПЛК панельки:

zaprosy ot PLC.png

А вот ответ ПЧ:

Proslushka.png

8) Параметры связи на ПЧ меняются точно без перезагрузки так как сначала я устанавливал связь с компа и после смены параметра 8.33 с 0 на 2 связь установилась без перезагрузки. А на ПЛК панельки эти параметры записываются в специальный регистр откуда потом читается. То есть что я туда запишу то и будет. А вот результат после смены параметров связи на контроллере и на ЧП:
а) на ЧП параметр 1 на контроллере 9600,О,8,1: диод связи постоянно горит на ЧП, программа которой ловлю обычно запросы-ответы не успевает их словить. В программе ПЛК выбивает ошибку контрольной сумы. Только после выключения запроса в программе ПЛК в окне программы которой открываю порт выводятся последние ответы. Вот они:

9600,O,1,8.png

б) на ЧП параметр 1 на контроллере 9600,О,8,2: то же самое, только диод быстро мигает. В программе ПЛК выбивает ошибку контрольной сумы. В этом случае как и в предыдущем приходит ответ (имею введу что в регистры ПЛК в которых должен записывается ответ записывается нужное значение чего не было в случае с функцией 06 и параметрами 9600,N,8,1).

9600,O,2,8.png

Пробовал использовать функцию 06 на тех параметрах на которых ПЧ дает ответ но результата нет. И не пойму почему так быстро запросы идут от панельки. Тайм-аут выставил 1,5 секунды.
в)на ЧП параметр 1 на контроллере 9600,О,7,1: ответа на ПЛК не приходит(регистры пустые)

9600,O,1,7.png

[alex_ugrumov]

по п. 7 не ясно.
Если у вас 2-х проводная сеть запросы и ответы передаются по одой паре и при прослушке нет возможности отделить запросы от ответов, должны идти одновременно: запрос, ответ, запрос, ответ. Как вы отделили запрос одно от другого? Может у вас 4-х проводная сеть.
Кроме того, то что вы называете ответами на самом деле не ответы, а искажённые запросы. Ответов там нет.

п8а - абсолютно нормальный обмен Запрос 020307.... ответ 020302.... То есть ПЧ, по крайне мере распознаёт запрос и отвечает.
п8б - абсолютно нормальный обмен то же самое.
п8в - мусор.

Ошибка контрольной суммы в панели - это может быть контрольная сумма RS, а не модбас

Вывод ПЧ настроен на 9600,8,1,odd. Убедитесь, что панелька тоже настроена на контроль чётности odd. Если она работает по none, то вот он и есть пропавший бит.

[AVeshnik]

Спасибо. Вышло записать в ЧП. Все дело, как Вы и говорили, в стопах и четности.
Связь устанавливается при проверке нечетных и 8 бит данных и одном стоповом бите.

[Jackson]

Спасибо. Вышло записать в ЧП. Все дело, как Вы и говорили, в стопах и четности.
Связь устанавливается при проверке нечетных и 8 бит данных и одном стоповом бите.

Осталось, напоследок, копнуть мануал на ЧП, наверняка эта информация там есть (а если нет то у саппорта эти вопросы должны на лету "от зубов отскакивать").

[Никита]

Мануал не лечит. Те же альтивары, 38-е лет 15 тому, когда я был уже не монтажником, но еще и не полноценным инженером, так по модбасу и не заработали. И самое смешное, что лет пять тому, сами шнайдеровцы сказали что глюки в частотниках все еще есть и не устранены.

[Jackson]

Мануал не лечит.

Но посмотреть его есть смысл.

[Jackson]

Что и требовалось доказать.
1. идём сюда
2. смотрим сюда:

danfoss.png

Сколько времени Вы потратили на поиск решения? Я затратил 5 минут включая скриншот и рамку.

[AVeshnik]

Спасибо, большое, всем кто откликнулся и помог решить проблему. ТЕВ, посмотрите внимательней, это настройка не Modbus RTU, а внутреннего протокола Данфоса-FC. Плюс какие настройки есть в русскоязычном мануале я скинул на скринах сверху. Но Вы правы. В англоязычному мануале не так описано.

Безымянный.png

Вывод: если Вас настораживает переведенный мануал, то нужно заглянуть на страницы его брата на языке оригинала! По крайней мере я так, от этого момента, точно начну делать. В противном случае это грозит, как заметил ТЕВ, потерей времени.

[Jackson]

Об этом и речь.

В противном случае это грозит, как заметил ТЕВ, потерей времени.

Причём, заметьте, не только Вашего.