Modbus + RS485 + Готовый шилд
- Войдите на сайт для отправки комментариев
Добрый вечер.
Нашел на ебай http://www.ebay.com/itm/181214698630?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649
Все просто и понятно.... Но вот засада, все библиотеки которые я видел, не требуют пина на котором будет сидеть переключение режимов RX/TX для 485 они просто пишут в Serial то что надо для ModBus. Схемотехника и AVR дело новое, и слова "чудо" и "религия" всплывают чуть ли не в каждой схеме :-)
Вот тут я никак чуда насчупать не могу.
Например в freemodbus есть такой код, в другой библиотеке очень похожий...
void vMBPortSerialEnable( BOOL xRxEnable, BOOL xTxEnable ) { #ifdef RTS_ENABLE UCSRB |= _BV( TXEN ) | _BV(TXCIE); #else UCSRB |= _BV( TXEN ); #endif if( xRxEnable ) { UCSRB |= _BV( RXEN ) | _BV( RXCIE ); } else { UCSRB &= ~( _BV( RXEN ) | _BV( RXCIE ) ); } if( xTxEnable ) { UCSRB |= _BV( TXEN ) | _BV( UDRE ); #ifdef RTS_ENABLE RTS_HIGH; #endif } else { UCSRB &= ~( _BV( UDRE ) ); } }
Так вот вопрос, надо ли включать RTS_ENABLE и есть ли пин которые отвечает за RX/TX для этого кода.
З.Ы. Я паралельно копаю мануол на регистры но пока понятнее не становится....
Начнем с того, что указанный модуль на ебее по сути есть голая микросхема MAX485 и если взять на неё доку там очень хорошо все расписано.
http://www.tlsoundandlight.com/ISC_Material/MAX485.pdf
У этой микрухи есть 2 выхода Receiver Output Enable и Driver Output Enable. Их можно смело объединить и завести на цифровой пин Ардуины. Это и будет переключение режима РХ/ТХ. И можешь с ней смело работать через Serial. Хочешь софт, хочешь хард (хотя с софтом там засада есть, если нужно могу посмотреть)
Т.е. эта микросхема умеет либо только передавать, либо только принимать.
И кстати обрати внимание, если послать в неё данные и отключить режим передачи до того, как они будут переданы, то данные могут передаться не все. Вот такая засада
Что это мне и так понятно....
Вопрос был именно в том, как присабачить этот шилд к готовым библиотекам протокола.
Написать, я тоже могу в принципе все что угодно, даже поправить могу если очень надо, просто не хочется трогать чужой код или писать свой протокол.
Начнем с того, что указанный модуль на ебее по сути есть голая микросхема MAX485 и если взять на неё доку там очень хорошо все расписано.
http://www.tlsoundandlight.com/ISC_Material/MAX485.pdf
У этой микрухи есть 2 выхода Receiver Output Enable и Driver Output Enable. Их можно смело объединить и завести на цифровой пин Ардуины. Это и будет переключение режима РХ/ТХ. И можешь с ней смело работать через Serial. Хочешь софт, хочешь хард (хотя с софтом там засада есть, если нужно могу посмотреть)
Т.е. эта микросхема умеет либо только передавать, либо только принимать.
И кстати обрати внимание, если послать в неё данные и отключить режим передачи до того, как они будут переданы, то данные могут передаться не все. Вот такая засада
Схема громко сказано.
Обычно у таких модулей 4 контакта + питание.
2 контакта это обычные Serial RX и TX
2 контакта переключение между приемом и передачей. Их объединяешь и кидаешь на цифровой порт ардуины. Его состояние соответственно будет переключением между приемом и передачей.
Схема громко сказано. Обычно у таких модулей 4 контакта + питание. 2 контакта это обычные Serial RX и TX
2 контакта переключение между приемом и передачей. Их объединяешь и кидаешь на цифровой порт ардуины. Его состояние соответственно будет переключением между приемом и передачей.
у этого http://www.lctech-inc.com/Hardware/Detail.aspx?id=608101e2-7167-4926-bd6...
{DI, DE, RE, RO} и { VCC, GND,A и B} - по второй группе выводов вопросов нет, а по первой непонятно.
DI Это TX Serial
RO это RX Serial
DE и RE соединяются и служат для переключения между режимом приема и передачи.
Подробнее см
http://www.tlsoundandlight.com/ISC_Material/MAX485.pdf
DI Это TX Serial, RO это RX Serial, DE и RE соединяются и служат для переключения между режимом приема и передачи. Подробнее см
http://www.tlsoundandlight.com/ISC_Material/MAX485.pdf
класс Serial наверное не подойдет, тк здесь нужно управлять третьей ногой 485-го интерфейса?
Почему же не подойдет. Как раз Serial очень даже подходит как Hardware, так и Software.
Но перед передачей или приемом нужно разумеется требуемое состояние выставить (прием или передача)
И с Software Serial осторожнее, помнится он у меня не сразу заработал, что то там подправлял в стандартной либе
Я вот такой класс использую для работы с RS485
Пугаться не нужно, тут накручено много для универсальности, передачи с подтверждением приема и тд
Все можно гораздо проще сделать
Но перед передачей или приемом нужно разумеется требуемое состояние выставить (прием или передача)
И с Software Serial осторожнее, помнится он у меня не сразу заработал, что то там подправлял в стандартной либе
Какой уровень (HIGH, LOW) нужно выставить перед приемом и передачей, к какому выводу подключить управление состоянием 485 для вашего скетча? Если его нужно выставить и перед приемой и передачей, то может быть установить в инициализации и не изменять дальше или тут дело сложнее ?
Стандартных способов и библиотек для работы с 485 нет ?
Раз Вы начинающий, в мой скетч лезть не нужно, т.к. это и не скетч вовсе, а класс. сам по себе он работать не будет
собственно вся работа с 485 состоит примерно вот в чем
Относительно стандартных либ для 485 насколько я понял нет
Раз Вы начинающий, в мой скетч лезть не нужно, т.к. это и не скетч вовсе, а класс. сам по себе он работать не будет
собственно вся работа с 485 состоит примерно вот в чем ...
Относительно стандартных либ для 485 насколько я понял нет
а в режиме ожидания приема, т.е. проверки буфера Serial.available() держать пин в низком уровне?
а в режиме ожидания приема, т.е. проверки буфера Serial.available() держать пин в низком уровне?
Да, именно.
Единственное, что нужно учесть это то, что после передачи Serial.write() нужно дать паузу. Например delay(10) перед переключением в режим ожидания приема. Это делается для того, чтобы MAX485 успел отправить данные
Интервала в 10 мсек может быть избыточно или недостаточно в зависимости от скорости и объема передачи . Читал про функцию Serial.flash() ожидает реального завершения отправки данных.
Я эту тему очень хорошо ковырял. И экспериментально и теоретически.
Serial не может знать, отправились данные или нет по той простой причине, что отправляет их MAX485, через свой буфер и своими средствами
Так что единственный вариант гарантировать отправку данных - это подбирать паузу после Serial.write()
Serial не может знать, отправились данные или нет по той простой причине, что отправляет их MAX485, через свой буфер и своими средствами .Так что единственный вариант гарантировать отправку данных - это подбирать паузу после Serial.write()
Прочитал описание MAX485 и делаю вывод - это аналоговый преобразователь уровней. Ни про буфизацию и размер буфера, ни про скорость передачи (MAX про нее не знает и синхронизация под эту скорость ему не нужна) в описании не упоминается. Сверхмалые задержки
Если ошибаюсь пожалуйста не стесняйтесь и поправьте меня.
Если ошибаюсь пожалуйста не стесняйтесь и поправьте меня.
RS485 это цифровой способ передачи http://vsolike.by/ra/RS485.html
Я так и понял, что MAX485 это аналоговый транслятор уровней (драйвер шины) и у него нет никакой буферизации, следовательно предположение о том, что момент завершения передачи неизвестен принципиально неверно.
А способ обработки информации в интерфейсе 485 конечно цифровой.
Да, с буфером я погорячился.
Однако все мои эксперименты с Serial и попытками заставить его дожидаться полной отправки провалились.
Если у Вас получится, отпишитесь
Однако все мои эксперименты с Serial и попытками заставить его дожидаться полной отправки провалились.
Если у Вас получится, отпишитесь
Глюк в функции Serial.flush () ? Давайте спросим у форумчан. Мне сейчас видится такая возможность ошибки - при низкой скорости передачи и высоком быстродействии МК, не дожидаясь завершения передачи (если понадобился Serial.flush в том виде, как он есть, значит функция передачи работает в фоновом режиме по прерыванию) не применив Serial.flash можно ошибочно изменить уровень управляющего сигнала на прием.
Тогда последовательный порт честно отработает передачу, но стрелочник-то уже переключил MAX485 в обратное направление передача на этом была оборвана.
А нормальная реализация ModBus для Arduino есть? С Master/Slave и 255 параллельно подключенными устройствами?
А нормальная реализация ModBus для Arduino есть? С Master/Slave и 255 параллельно подключенными устройствами?
Помоему там только 32 на каждую линию :-)
Смотря что вы называете нормальной ? если полную в соответсвии со стандартом, то помоему нет, да их и под другие платформы халявных нет :-) А если базовый функционал, то я встречал 2 или 3.
Помоему там только 32 на каждую линию :-)
Смотря что вы называете нормальной ? если полную в соответсвии со стандартом, то помоему нет, да их и под другие платформы халявных нет :-) А если базовый функционал, то я встречал 2 или 3.
Да попутал. Не 255 а 247
http://ru.wikipedia.org/wiki/Modbus
Нормальной я считаю, что любой Modbus ANSI/RTU драйвер SCADA системы будет втдеть ведомые ардуинки.
Идея в том, что 485 достаточно дешевая сеть, работающая на большом расстоянии всего по 2-м проводам, а Modbus протокол позволит интегрировать контроллеры с платной/бесплатной SCADA.
Можете предложить другой способ увязать все Arduino в ожну сеть с ПК кроме RF 2.4?
Идея в том, что 485 достаточно дешевая сеть, работающая на большом расстоянии всего по 2-м проводам, а Modbus протокол позволит интегрировать контроллеры с платной/бесплатной SCADA.
Можете предложить другой способ увязать все Arduino в ожну сеть с ПК кроме RF 2.4?
Хм.... Ну вариантов много, вопрос только в цене... например простой Ethernet сильно удобнее ну и дороже конечно.
Я тоже выбрал эту связку 485 + Modbus. но есть некоторые моменты где надо обратную связь... и тут уж либо думать пулинг умный или другие способы связи RF 2.4 - очень проблемно... особенно коллизии.... Ethernet - очень дорого
Можете прислать исходник? Пытаюсь Ваш класс прикрутить к своему проекту, ничего не выходит. Я не профессионал, буду благодарен если пришлете кусок кода где можно увидеть инициализацию порта и чтение / запись.
Спасибо!
Доброго времени суток!
Нашлось програмное решение МodBus RS485?
Сколько единиц на линии 485 зависит от микросхемы-драйвера 485: 16/32/64/128/255 нужно читать даташит и смотреть схемотехнику устройства.
Микрохема-драйвер RS485 преобразует отдельные физические уровни TTL (0..5v) приема и передачи в диференциальный сигнал линии связи RS485.
Драйвер занимается ТОЛЬКО физической стороной приема-передачи. Всю логическую сторону формирования байта берет на себя UART/USART. Дополнительно программа пользователя занимается устаноовкой направления работы драйвера "прием" (всегда) "передача" только на время передачи данных.
Важно вовремя перевести драйвер на прием. Если это сделать рано, то мы не передадим (последний) байт. Если опоздаем, то можем пропустить прием байта. Если говорить об AVR контроллере, то, например, тут: http://avr.ru/ready/inter/usart/uart
USART Control and Status Register A – UCSRA.
Bit 6 – TXC: USART Transmit Complete – этот флаг устанавливается по завершению передачи байта. Он также может быть источником прерывания (если разрешено прерывание по завершению передачи и разрешены прерывания, будет сформировании запрос).
Bit 5 – UDRE: USART Data Register Empty – флаг опустошения регистра данных(указывает, готовность к приему/передачи следующего байта), если бит установлен, передатчик/приемник готов.
Думаю нам нужно смотреть "Bit 6 – TXC: USART Transmit Complete". Дело в том, что есть буфер, в который наша программа забрасывает байт на передачу (свободно - бросаем байт - USAR передает), а есть сверхопативный буфер из которого биты передаются в линию, затем формируется паритет, стоповый бит и только тогда передача завершена - установить 485й на прием! Таким образом у программы фактически есть аппаратный буфер почти на 2 байта.
Поскольку на 485й линии все устройства стоят параллельно, то драйвер RS485 нужно максимально быстро ставить на прием после перезагрузки и не допускать ложного устанавливания его на передачу - в таком случае линия будет заблокирована и общение всех остальных устройств будет невозможным.
Поскольку на 485й линии все устройства стоят параллельно, то драйвер RS485 нужно максимально быстро ставить на прием после перезагрузки и не допускать ложного устанавливания его на передачу - в таком случае линия будет заблокирована и общение всех остальных устройств будет невозможным.
Помоему ведомое устройство прежде чем передать мастеру по его запросу данные, ждет окончания передачи. То есть оно не начнет передавать пока линия физически не освободиться, то есть пока мастер не "замолчит", и только после этого спустя какой-то таймаут, он начнет ответ мастеру.
тут надо понять, что делает драйвер если его перевести в передачу, но ничего не передавать. Будет ли он занимать линию или нет. Но я даташит на мах485 не курил на эту тему пока. Если драйвер стоит на передаче(пин на прием мы не переключили), то ведомое устройство по идее должно как раз ожидать его переключения и только потом передавать
я делал slave ардуинку
если нужна библиотека, могу скинуть
мне нужен мастер, но я уже смотрю тему с SimpleModbusMaster тут http://arduino.ru/forum/proekty/modbusrtu-modbustcp-arduino-i-owen-plc#comment-210568
правда там непонято с обработкой ошибок..
2James
Добрый день, как раз интересуюсь слейвом на ардуине. Скиньте плс. библиотеку.
Большое спасибо
+1 больше спасибо! :)
Не было ни у кого зависаний дуинки с модулем? не могу понять, в чем косяк. постоянно горит Rx, если отключить модуль, то мигает в ожидании, причем, без модуля, через уарт, та же история.
п.с. было найдено, что при отключении 10 пина, дуинка начинает общаться через уарт нормально.
Не было ни у кого зависаний дуинки с модулем?
Я собрал проект в котором многое чего есть. И все в сумме начало зависать. За сутки раз 20-30. В чем дело - я не смог определить. Показалось, что дело в индикаторе TM1637 - он чаще всего "тух". Нашел статью про WDT - включил. Повезло - моя UNO поняла WDT без танцев с бубном. Однако частота зависаний однозначно зависит от работы modbus, а это в принципе не есть хорошо. :(
Пока так оставил.
заказал еще один модуль, через пару дней попробую. такое ощущение, что что-то держит линию и не дает переключится обратно. Сейчас попробую танцы с другим компом. другой контроллер пробовал, проблема остается. Пайка нормальная, проверил на макетке, ошибка повторяется. Не мог ли я случайно сжеч переходник uart-rs485? потому, что бага начала появляться после подключения к блоку питания
бага начала появляться после подключения к блоку питания
Есть такая тема, как защитная подтяжка.
Описано что-то на английском тут: http://0xee.net/2014/07/02/pic-talks-uart-on-rs-485/
Картинка:
Резисторы R1 и R2.
Эта подтяжка предназначена рержать логический "1" на линии , когда все передатчики отключены. Если ни в одном из устройств такой подтяжки нет - возможны помехи приема, когда никто не передает. Но если такие подтяжки есть на всех устройствах, то может не хватить мощности выходного каскада микросхемы RS485 для того, что бы передавать сигнал. В одном из случаев пршлось в готовом устройстве эти резисторы откусить, т.к. когда их поставили на линию 4 шт в параллель - связь пропала.
Я же припоминаю, что у меня на столе возникли проблемы. Я смотрел что у меня происходит в линии терминалом... обнаружил, что-то на линии, когда никто не передает и "вылечил" нагрузочным резистором + резисторы подтяжки. Хотя в "заводских" решениях ни разу с такой проблемой не столкнулся.
В случае с представленной схемой как раз есть джампера что бы подтяжку и нагрузочные сопротивления включить на крайних устройствах и отключить на всех промежуточных.
на вашей схеме заметил R4, нужно будет попробовать подтянуть на землю.
В итоге - не помогло, зависание полное
у меня вот такой
на вашей схеме заметил R4, нужно будет попробовать подтянуть на землю.
В итоге - не помогло, зависание полное
То, о чем я говорил - это R5, R6, R7 (судя по прозвонке тестером).
т.е. попробовать их закоротить?
т.е. попробовать их закоротить?
Не! Нельзя.
Жалко, что нет осциллографа. Можно бы посмотреть что на линии.
Я когда тренировался - я сделал управление прием передача меандром на 5 секунд. Т.е. прием 5 секунд. Передача 5 секунд (скажем 0x55 или 0xFF). И смотреть что происходит на линии параллельным 485-USB преобразователем. Все должно происходить четко.
чего нет, того нет:( есть только мультиметр:(
пришли новые, теперь косяк в том, что при включении модуля и попытке опросить устройство горит RX и нет ответа, такое ощущение, что комп держит линию, хотя через ЮСБ шнурок без модуля все отлично работает. Никто не сталкивался?
походу Максимка сгорел:(
Кто разбирался с библиотечкой? Тестирую с программы ModBus Tester v0.3
У меня нормально работает с адресами переменных с 1 по 10.
Если задать адрес 0 - программа на ардуино зависает.
Если обращаться к адресам более более 11 (?) Arduino в протокол выдает ошибку "не правильный адрес".
Я нашел, что буфер 64 байта. А где расширить диапазон возможных переменных - не нашел :(
А библиотека для связи с устройствами ОВЕН существует?
А библиотека для связи с устройствами ОВЕН существует?
они все работают по ModBus RTU, а очень многие еще и по ASCII