Четверг, 21.06.2018, 21:39
| RSS
Главная | Радиомодуль - Страница 38 - Форум
Защита, контроль, управление
Форма входа
Логин:
Пароль:
[ Новые сообщения · Участники · Правила форума · Поиск · RSS · Чат ]
  • Страница 38 из 38
  • «
  • 1
  • 2
  • 36
  • 37
  • 38
Модератор форума: Zoolu  
Форум » ФОРУМ » Домашняя автоматизация на Raspberry Pi » Радиомодуль
Радиомодуль
AdminДата: Среда, 02.05.2018, 12:00 | Сообщение # 371
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
Цитата AlexAW ()
А имеет ли смысл делать все 31 кнопки, и индикаторы. Ведь част кодов может быть использована только для приема например команд с датчиков, а часть кодов, только для передачи, (например управление радиореле) или перехвата люстры.

Оно то все так, но возможно кому-то понадобится только передача (управление), а кому-то только контроль. Или большой "дисбаланс" этих функций - например, 5 на управление, 29 на контроль (или наоборот).

Цитата AlexAW ()
Может определить несколько кнопок несколько индикаторов и несколько кнопок с индикаторами, только с возможностью привязки определенного номера команды к соответствующей кнопке (индикатору) а за одно  можно было бы и действие прикрутить к получаемым командам, а передаваемые команды , как действие применить и на других страницах -
например температура достигла определенного уровня выбираем действие передать команду привязанную к радио кнопке 1
Или при получении радиосигнала с датчика протечки подать команду на включение реле ХХ,
Или при получении команды от датчика протечки о снижении питания послать СМС сообщение №1
ну итд итп

Так для этого кнопки и входы необязательно визуализировать в форме, можно это делать и "внутри" сценариев.
 


AdminДата: Четверг, 03.05.2018, 12:55 | Сообщение # 372
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
Александр,что-то я туплю, поэтому два уточняющих вопроса:

1. Полностью код занимает 4 ячейки в памяти, например, 0х00, 0х01, 0х02, 0х03, непосредственно сама кодовая посылка - это байты из ячеек 0х01, 0х02, 0х03. При выполнении функции 06 и Lo=1 именно она передается в эфир. Правильно?

2. При чтении входов возвращается непосредственно сам код (три байта 0х01, 0х02, 0х03) или просто флаг (0/1) что данный вход сработал (т.е. радиомодулем был принят соответствующий код)?
 
AlexAWДата: Четверг, 03.05.2018, 15:38 | Сообщение # 373
Группа: Участники
Сообщений: 195
Статус: Offline
Цитата Admin ()
1. Полностью код занимает 4 ячейки в памяти, например, 0х00, 0х01, 0х02, 0х03, непосредственно сама кодовая посылка - это байты из ячеек 0х01, 0х02, 0х03
Да все верно передается содержимое ячеек 0х01, 0х02, 0х03 с частотой модуляции определяемой значением в младщем полубайте ячейки 0х00 (см. Таблица расчета периода.xls столбцы 1 и 3) При записи радиокоманд в режиме "обучения" код частоты модуляции вычисляется и записывается автоматически таким что бы передаваемый потом  радиомодулем код, передавался с частотой модуляции близкой к частоте записываемого с устройства (датчика, пульта итд итп)
Передается радиокод из ячеек  0х01, 0х02, 0х03 по команде ModBusRTU функция 6 адрес регистра 0х0004, значение 0х0001
значение 0х0001 - это номер кодовой посылки записанной в память радиомодуля в ячейках  0х00, 0х01, 0х02, 0х03 (подробнее см. Таблицы команд управления блока радиоприема.xls)
Цитата Admin ()
2. При чтении входов возвращается непосредственно сам код
Не совсем понял вопрс под чтением входов - понимается команда ModBusRTU функция 4?
Командой ModBusRTU функция 4 адрес регистра 0х0000 читаются номера полученных (известных радиомодулю и записанных в его памяти радиопакетов)команд. те. радиомодуль получив радиокоманду от известного ему модуля записывает номер полученой команды в буфер приема, приходит следующая посылка записывается следующий номер в буфер. В буфер записываются только номера команд. понятно, что не известные радиомодулю посылки хоть и будут приняты но в буфер команд не попадут. Всего в буфере сохраняется до 16 номеров команд. когда мы выполняем команду ModBusRTU чтения номера полученной радиокоманды из буфера, радиомодуль выдает первую по очереди поступившую команду, при следующем чтении, вторую итд. до тех пор пока буфер не освободится как только он освободится мы прочитаем  0х00. Это означает, что буфер пуст. Процесс записи и чтения буфера может происходить одновременно. Наличие буфера позволяет легко решить проблемы синхронизации приема команд и их обработки ЦУ.

Не известную но принятую радиокоманду возможно тоже принять и обработать, но только одну последнюю принятую. для этого используются две команды чтения функция 4 адрес регистра 0х0001 и адрес регистра 0х0002. Этими командами ModBusRTU считываются два двухбайтных числа т.е четыре байта. В первом байте содержится значение периода модуляции модуляции если это число умножить на 8 получим средне измеренное значение периода одного байта в мкс. остальные три байта содержат полученный код.


Сообщение отредактировал AlexAW - Четверг, 03.05.2018, 16:15
 
AdminДата: Четверг, 03.05.2018, 17:35 | Сообщение # 374
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
Александр, под "чтением входов" я имел ввиду следующее - что возвращает радиомодуль в малину после приема "знакомого" ему кода?
У меня это было реализовано следующим образом - есть массив "принимаемых" кодов, записанных в EEPROM. Каждый код состоит из 4 байт - собственно сам код и четвертый байт, так называемый номер зоны. Фактически номер зоны - это условно и есть "номер входа". Приемник приняв "знакомый" ему код, выставляет флаг (1) возвращает в малину информацию, что данный код был принят (т.е. сработал определенный "вход"). А малина видит, что в данном регистре флаг поднят и меняет индикацию "входа".
 
ZooluДата: Четверг, 03.05.2018, 19:07 | Сообщение # 375
Группа: Модераторы
Сообщений: 457
Статус: Offline
Admin, тут радиомодуль возвращает номер от 1 до 31 принятой известной команды. Нужно читать до опустошения буфера.
 


AdminДата: Суббота, 05.05.2018, 20:14 | Сообщение # 376
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
Цитата Zoolu ()
тут радиомодуль возвращает номер от 1 до 31 принятой известной команды. Нужно читать до опустошения буфера.

Спасибо, Антон, понял.

Так, теперь еще пару вопросов.
1. По функции 03 считываются данные из ячеек EEPROM (т.е. коды, которые записаны и хранятся в памяти)?
2. По функции 04 из нулевого регистра считываются данные номера последней принятой команды (1-31), из первого регистра 1 и 2 байты и из второго регистра 3 и 4 байты последнего принятого кода. Вопрос - после вычитывания этих данных номер команды обнуляется, а данные кода продолжают "висеть" до приема следующей команды. Но судя по всему они после чтения тоже должны обнуляться? Или это относится только к буферу с номером команды?

В принципе, это вопросы только для уточнения и понимания. Сделал отдельный интерфейс для радиомодуля Александра, формирующий 31 команду и соответственно, отображение состояния 31 датчика. Теперь около двух недель буду отсутствовать, когда прилечу, доведу оформление до ума и тогда уже выложу первую версию интерфейса. Всем пока  hello
 
AlexAWДата: Вторник, 08.05.2018, 05:11 | Сообщение # 377
Группа: Участники
Сообщений: 195
Статус: Offline
Цитата Admin ()
Так, теперь еще пару вопросов.
1 Да по функции 3 читаются данные из ячеек EEPROM. тем самым можно прочитать коды команд записанных в режиме записи кодов и (или) проконтролировать то что записывалось через ModBus интерфейс.
2 Да данные последней принятой команды ежат в регистрах до прихода следующей. Фактически и буфер тоже не стирается а пишется поверх тк он кольцевой и когда указатель адреса записи буфера, совпадает с указателем адреса чтения читается 0х00. 
Хорошего отдыха.
К приезду материалы к публикациям приготовлю....

Добавлено (08.05.2018, 05:11)
---------------------------------------------

Цитата Admin ()
доведу оформление до ума и тогда уже выложу первую версию интерфейса.
Команды чтения последнего принятого пакета и чтения и записи в EEPROM, по моим задумкам относится к категории отладочно-настроечных команд. И их не стоит выводить в ВЕБ интерфейс. Что бы не загружать лишними опросами ModBus обмен. 
 
Что касается обнуления регистров после чтения последней принятой команды - можно конечно сделать и так для  одинаковости протоколов обмена.
Я исходил из логики, что во время чтения кодов может произойти прием уже другой команды, и для убеждения того что это последняя и считаная правильно следует повторить чтение и сравнить если то же значит точно последняя. В варианте с очисткой регистров приема тоже требуется второе считывание, правда процедура сравнения будет немного проще просто с нулем. Тем не менее второе чтение потребуется.....
Так что не знаю стоит ли вносить изменения....
Хотя наверно стоит - аргументов за внесение изменений  больше контроль проще, и интерфейс понятней и одно образней.
 
AdminДата: Вторник, 08.05.2018, 15:02 | Сообщение # 378
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
AlexAW, предварительно я спланировал следующую концепцию интерфейса:

1. 31 команду (управление) запихнуть под спойлер на странице
2. Сработку входов фиксировать в лог  с меткой времени и выводить на страницу, допустим, последние 10. В случае необходимости можно посмотреть полностью весь лог. Предусмотреть кнопку очистки лога.
3. Кроме записи в лог, каждая сработка должна фиксироваться как событие, которое, в случае необходимости, можно привязать к какому-либо сценарию. Как тут лучше это дело организовать, прикидываю варианты.
4. Предусмотреть возможность вывода всего массива кодов из EEPROM для просмотра (контроля). Вообще будет неплохо дополнительно предусмотреть возможность корректировки сохранённых кодов и загрузку их обратно в микроконтроллер через RS485. Разумеется, в постоянном опросе эти данные не нужны, только в процессе отладки.

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

Всех с наступающим самым главным праздником - Днём Победы!!!
 
AlexAWДата: Вторник, 08.05.2018, 18:39 | Сообщение # 379
Группа: Участники
Сообщений: 195
Статус: Offline
Ну вот, а я уже и правки внес в программу для более удобного чтения и записи в EEPROM. Сделал команды чтения и записи одинаковыми по структуре управления. И включил очистку содержимого значений последней принятой команды после прочтения.
Внесенные изменения несколько упростят управление радиомодулем по ModBusRTU. правда пришлось передвинуть адреса регистров записи в буфер команды для передачи и команды очистки буфера приема, что естественно потребует правки в скрипты. Но пока я так понима это вполне возможно, тем более совсем не сложно.
Для тех кому интересно внизу поста файл с архивом в котором содержится новая версия прошивки, схема с дополнениями и таблицы с командами ModBusRTU, так же краткий файлик с описанием разработанной программы.
Прикрепления: Public_radiomod.zip(58.8 Kb)
 
AdminДата: Пятница, 18.05.2018, 22:02 | Сообщение # 380
Admin
Группа: Администраторы
Сообщений: 3874
Статус: Offline
Цитата AlexAW ()
Внесенные изменения несколько упростят управление радиомодулем по ModBusRTU. правда пришлось передвинуть адреса регистров записи в буфер команды для передачи и команды очистки буфера приема, что естественно потребует правки в скрипты. Но пока я так понима это вполне возможно, тем более совсем не сложно.

Подкорректировал скрипты под последнюю версию прошивки контроллера radio485pp_v1.31.HEX
В общем, пока получается примерно так:



Прикрепления: 7723481.jpg(169.6 Kb) · 3426987.jpg(287.8 Kb)
 
Форум » ФОРУМ » Домашняя автоматизация на Raspberry Pi » Радиомодуль
  • Страница 38 из 38
  • «
  • 1
  • 2
  • 36
  • 37
  • 38
Поиск:



T2M © 2018
Сайт управляется системой uCoz