Получение данных по RS-485 с EPsolar Tracer A (BN)

РЕКЛАМА НА ФОРУМХАУС

Проверьте на разных бодовых скоростях. Настройте свой MAX485 на прием, подклчитесь к кабелю, когда по нему идет обмен с РС, и слушайте, перебирая бодовые скорости, пока не появится осмысленная информация.

 

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

 

Чтобы избавиться от шума, надо реализовать протокол Modbus. Очевидно у вас там Modbus RTU. В протоколе сказано, что приемник должен сбрасывать свой буфер, если услышит паузу длительностью более 3.5 байт-интервалов. Валидное сообщение передается с короткими паузами между байтами, или вообще без пауз, зато перед началом Modbus сообщения всегда есть пауза, по которой все приемники очищают накопленный мусор. Принятое сообщение проверяется, его длина должна соответствовать декларированной длине, которая передается в начале сообщения, а само сообщение покрыто двухбайтным CRC. Не прошедшие проверку сообщения отбрасываются.

 

вы не про бывали снять лог ?

 

@kentlute, неа... картошка и изготовление новой панели были в приоритете

 

Спасибо за совет, но реализация Modbus RTU не избавляет от шума в канале, который составляет 90% потока данных Modubus - это просто протокол. Собственно его изначально и реализовывал, с проверкой CRC, однако шум в канале появлялся помимо моей воли, какие бы интервалы не выдерживались.
Но всё оказалось гораздо проще. Собственно в статье, ссылку на которую прислал уважаемый Weis, была зарыта ключевая фраза :

Объединение "земли" Ардуинки и Esolar решило проблему.
Теперь в канале ничего лишнего кроме моих запросов и ответов Epsolar

 

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

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

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

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

 

Есть вот такая программка для экспериментов с Modbus
https://www.modbusdriver.com/modpoll.html
Исходники для общения с Tracer:
https://github.com/kasbert/epsolar-tracer
Сам попробовать пока не могу - мой контроллер раньше апреля до меня не доедет (специфика места обитания)

 

Информация для программистов:
Выяснились особенности работы кабеля-переходника usb-rs485.
Оказалось, что кабель хотя и опознается линуксовым модулем cdc_acm,но
без некоторой настройки встроенной в него микросхемы просто так не работает.

Готового продукта под Линукс с красивостями для пользователей пока что похоже нет ни у кого.
Но желание с этим повозиться лично у меня есть.

 

На днях солнечный контроллер до меня наконец-то доехал.
Произвел некоторые эксперименты с вышеупомянутыми питоновскими исходниками.
Замечу, что там вместе с ними на Гитхабе лежит и описание регистров контроллера. Не буду его сюда прикреплять, кто интересуется - может и там скачать.
Выводы:
для той микросхемы что стоит в штатном кабеле usb-rs485 от контроллера - есть два вырианта поддержки в линуксе. Модуль от производителя чипа, и штатный модуль ядра - cdc_acm.
Модуль от производителя чипа Exar, слегка поправленный автором исходников - после небольшого подпиливания собрался у меня под ядро 3.4.104 на ARM-процессоре. Работает но сыплет ошибками в системный журнал, что кажется мне эстетически некрасивым. Да и расчитывать что он соберется под другое произвольно взятое ядро - не приходится.
Сами питоновские исходники тоже чуть подправить пришлось, но и те и другие исправления самоочевидны. Написано это на Питоне конечно скажем там весьма своеобразно.
Однако результат есть - информация из контроллера читается. Правда весьма медленно работает питоновская библиотека pymodbus. Попробовал написать чтение данных на Си используя сишную
библиотеку libmodbus. Это намного быстрее. Да и писать на Си куда проще чем разбираться в питоновом авторском стиле. После чего решил попробовать попробовать избавиться от стороннего ядерного модуля поддержки чипа Exar. Загрузил штатный cdc_acm. Устройство ttyACM0 образовалось, но не работает. Оказалось надо послать чипу команду на переключение одной из ног из режима gpio в режим поддержки rs485. Нашел даже готовый кусочек исходника, сделанный на libusb. Легко можно нагуглить по слову corExar. Лежит на одном форуме, ссылку на который модераторы тут видеть не хочут. Собственно, весь исходник - вокруг вот этого:
Меняются регистры:
CDC_ACM_GPIO_MODE (0x217) — с 0x01 до 0x0b
CDC_ACM_GPIO_DIRECTION (0x218) — с 0x08 до 0x28
CDC_ACM_GPIO_INT_MASK (0x219) — с 0x30 до 0x00
CDC_ACM_FLOW_CONTROL (0x216) — с 0x01 до 0x00
Самое важное - первая строчка. Остальное - подсмотрели в виндовом драйвере, не факт что оно надо.
При случае - проверю работает ли без этого.
После того как эти регистры в микросхеме поменяны - чтение данных посредством сишного libmodbus начинает работать, и быстро. А вот исходник на Питоне почему-то не работает с модулем cdc_acm даже после перенастройки регистров микросхемы. Есть предположение что питоновая библиотека не выполняет необходимые настройки порта для работы в режиме rs485. Про это в документации к линуксовому ядру есть файлик /doc/Documentation/serial/serial-rs485.txt
Но с этим пусть любители Питона разбираются если таковые тут обнаружатся. На Си чтение работает и меня это более чем устраивает. А вот теперь возникает несколько более сложная задачка - придумать "архитектуру" программы которая будет с контроллером общаться. Это уже не то что готовые библиотеки дергать, ядерные модули ковырять и осциллографом в линии данных тыкать. Буду думать как лучше сделать.
Минимальный "непричесанный" исходник на Си для чтения первых восьми регистров контроллера - прилагается. Ну это чтобы если кто поковыряться захочет - то не совсем с пустого места начинать.
На копирайт не претендую - нашел его на каком-то буржуйском форуме и исправил несколько ошибок, из-за которых у автора и не работало

 

@WatchCat, как впечатление о контроллере, не жалеете что приобрели?

 

есть же готовая программа? на сайте производителя

 

А чего мне жалеть? Мне этот контроллер достался намного дешевле чем те настоящие контроллеры которые рекламируются как обязательные к использованию. Они за ~30тыс,а этот примерно 10 обошелся.
Три поездки в магазин за едой
Насчет впечатлений пока сказать ничего не могу - лежит он у меня на столе в домашней лаборатории в качестве подопытного кролика и я с ним разбираюсь. Вот когда разберусь с настройками и в работу поставлю - тогда можно будет что-то определенное сказать, да и то не сразу, а через месяцы.

Мало того что малополезная и неудобная, так еще и под винды. Я последний раз с виндами возился больше десятка лет назад, да и то так, побочно, на работе если помочь просили. Воевать с их глюками, да еще в деревенских условиях - абсолютно никакого желания не имею. Ну и энергии сколько комп с виндами скушает - даже представить страшно. Так-то я могу обойтись компом на ARM с потреблением десяток ватт.
А от программы мне надо в первую очередь запись данных в файлы чтобы потом можно было всякую статистику считать и графики рисовать. Есть для этих целей в линуксе много всяких очень хороших средств. Потому как без анализа действительно хорошей статистики - настройки крутить бессмысленно, это вслепую получится.

 

Как вариант может использовать наработки @Osolemio:
https://www.forumhouse.ru/threads/319993/page-50#post-18445865
"Прилепить" к нему чтение данных со своего контроллера, а выдачу куда душе угодно. Тем более, что это уже делалось для старого EPSolar'а @Cronex.
Хотя бы на те же сервера:
https://emoncms.org/ да https://narodmon.ru/ или на свои любимые.

 

За ссылку спасибо, о наработках почитаю, идеи утащу

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