Доброго времени суток, уважаемые Хабровчане.
Эту статью условно можно разделить на три части. В первой, речь пойдет о преобразователях интерфейсов RS232/Ethernet — что это такое и как используется.
Во второй, на примере создания шлюза ModBus ASCII_RTU/ModBus TCP продемонстрирую возможность программирования преобразователей Tibbo.
И, наконец, в третей части попробуем создать автоматическую систему управления отоплением, из немного модифицированного преобразователя интерфейсов Tibbo, с возможностью посылать команды средствами смс сообщений, веб-интерфейсом управления и выгрузкой данных в MySQL.
Под западным понятием Serial Device Server подразумевается преобразователь интерфейсов Serial (RS232/422/485) в Ethernet. Потребность в подобных устройствах возникла по простой причине: практически любой микроконтроллер, вне зависимости от производителя, для связи с «внешним миром» использует интерфейс UART (это связанно с технологической простотой реализации данного интерфейса) на TTL или CMOS логике. Таким образом, разработчику достаточно подключить к контроллеру микросхему приемо-передатчика, чтобы получить канал передачи данных по интерфейсу RS232/485. Но последовательные интерфейсы не обеспечивают достаточных характеристик для создания современных коммуникационных систем. С другой стороны, существует развитая технология Ethernet, которая позволяет создавать локальные подсети, объединять их и организовывать каналы передачи данных между географически разнесенными точками по всему миру. Логично, что производители коммуникационного оборудования решили «объединить» последовательные интерфейсы и технологию Ethernet. Таким образом, появились аппаратные шлюзы, под названием Serial Device Server.
Преобразователи интерфейсов RS232/Ethernet от Тайваньской компании Tibbo Technology уже на протяжении 10 лет используются по всему миру. За это время инженерами компании был накоплен огромный опыт по реализации проектов с использованием данного оборудования, были решены нетривиальные задачи, а функционал устройств расширен до нового уровня, далеко выходящего за рамки «обычных» преобразователей. Данная линейка устройств имеет название Tibbo Device Server – программируемые преобразователи интерфейсов. Ключевым словом в данном определении является слово «программируемые», т. к. конечный функционал устройства полностью зависит от той прошивки, которая была создана и загружена в него.
Но начнем с простого.
Конструктивно, устройства Tibbo Device Server (DS) представляют из себя небольшую коробочку размером с пачку сигарет. С одной стороны находится стандартный разъем (или несколько разъемов) для последовательного интерфейса, с другой — розетка для подключения витой пары по технологии Ethernet. По умолчанию, Tibbo Device Server поставляется с прошивкой “Serial Over IP”, которая позволяет передавать данные между интерфейсам RS232/485 в Ethernet.
После физической коммутации необходимо настроить параметры устройства. Для этого используется набор утилит от производителя: DS Manager – предназначен для настройки параметров устройства, VSP Manager – для настройки параметров виртуального COM порта, драйвер виртуального COM порта и несколько диагностических утилит. Я не буду подробно останавливаться на описании настроек, но обращу ваше внимание на некоторые особенности данных утилит:
Преобразователь интерфейсов может быть настроен на один из трех режимов. Режим клиента — это когда последовательное устройство является инициатором Ethernet соединения. Такой режим используется для пассивного мониторинга. Например, когда АТС с определенным интервалом скидывает на сервер статистику. Или сканер штрих кода передает данные в 1С. В данном режиме вы задаете ip-адрес, на который необходимо отправить данные, а виртуальный COM порт сервера прослушивает TCP/IP порт на наличие входящего потока данных.
Режим сервера — последовательное устройство отвечает на входящий запрос. Такой режим может использоваться для опроса модулей ввода/вывода, ПЛК, счетчиков и т. д.
Режим сервер/клиент — совмещает оба указанных выше варианта. В этом случае виртуальный COM порт сервера умеет как слушать входящий поток данных, так и устанавливать соединение с устройством по указанному ip адресу. Где могут использоваться подобные решения? Это множество вертикальных рынков и прикладных задач. Например:
Многие зададут вопрос, а чем устройства Tibbo лучше аналогов (которых достаточно в данном сегменте)? Я не буду детально сравнивать технические характеристики, которые у большинства аналогичных устройств идентичны друг другу. Упомяну лишь о важных особенностях преобразователей Tibbo:
Но главное отличие от конкурентов — преобразователи Tibbo являются программируемыми! Что если указанного функционала не хватает и нужно что-то особенное? Давайте разберемся, как этого можно достигнуть и как можно раскрыть полный функционал Device Server от Tibbo Technology.
Что если на объекте установлена Scada система, которая опрашивает устройства по протоколу ModBus TCP. А нам требуется опросить устройство с протоколом ModBus RTU и последовательным каналом RS232 на борту. Подключив обычный преобразователь интерфейсов RS232, получим выход в локальную сеть и даже Интернет, но Scada не увидит никаких данных без реализации протокола ModBus.
Вот здесь и приходит на помощь главная особенность преобразователей Tibbo — возможность программирования.
Программы кодируются на событийном объектно-ориентированном языке Tibbo Basic. Кратко я об этом писал в статье о Tibbo Project System. На данный момент готов компилятор для языка «С» и в скором времени состоится его релиз. Таким образом, вы сможете выбирать язык программирования — функциональный и глубокий «С» или более простой, легкий в понимании Basic.
Среда программирования Tibbo IDE распространяется бесплатно. Для отладки программ и прошивки не требуется никаких программаторов, все осуществляется прямо через локальную сеть Ethernet, включая пошаговый режим прохода программы и точки останова.
Итак, для реализации нашей задачи (опрос устройства с ModBus RTU), нам требуется реализовать протокол ModBus для оборудования Tibbo. К счастью, протокол уже написан и находится в открытом доступе. Нам достаточно скачать его с сайта, подключить к проекту, скомпилировать, прошить устройство и мы получаем шлюз ModBus RTU в ModBus TCP.
Вот как выглядит проброс данных в исходном коде, после подключения библиотек.
Расширим задачу. Последовательное устройство вообще не поддерживает протокол ModBus, а так хочется подключить его к Scada системе. Тогда запрограммируем опрос необходимых метрик устройства по обычному интерфейсу RS232, берем код ModBus TCP и получаем аппаратный драйвер специально для вашего устройства.
Можно и дальше расширять задачу — необходимо резервное копирование данных в случае обрыва связи? Используем встроенную флеш-память на 1 Мбайт и храним данные автономно, до восстановления связи. Нужна настройка через веб-интерфейс? Программируем встроенный веб-сервер и получаем заданный функционал.
Таким образом, вы можете реализовать любой протокол, создавая собственные аппаратные драйвера устройств и даже больше. Вы можете программировать логику, получая свой собственный маленький ПЛК.
Однажды мне попалась довольно интересная задача. В частном доме установлена система отопления — два электрических водонагревательных котла. На выходе котла и в обратной ветви трубопровода установлены датчики температуры воды, также в системе присутствуют датчик избыточного давления и датчик температуры наружного воздуха. Все датчики были заведены на модуль аналогового ввода МВА8 (ОВЕН), который «общается с миром» через интерфейс RS485. Задача — удаленный мониторинг показаний датчиков. В идеале, система должна записывать значения в базу данных MySQL для дальнейшего отображения информации на личном сайте заказчика. Я выбрал устройство DS1102.
Первое, что нужно было сделать — реализовать протокол передачи данных для модуля МВА8. Протокол достаточно простой и на кодирование было потрачено несколько часов, в результате была получена пара полезных функций для работы с модулем аналогового ввода, среди которых get_data_sensor(). Следующим шагом была реализация протокола MySql. Тут я потратил чуть больше времени. В результате и эта задача была решена за несколько часов. Готовая библиотека MySql опубликована на сайте производителя.
Итак, DS1102 теперь умеет обращаться к базе данных MySql, умеет опрашивать МВА8, пора заняться простейшей логикой — опрашивать датчики и записывать значения в базу данных.
Все работает, данные успешно передаются в таблицу MySql. Заказчик доволен и уже готов был отметить успешную реализацию, как вдруг спросил: «А можно удаленно управлять температурой в помещении?». Ну что же, раз хочется, значит сделаем.
В цепи питания котлов производителем была предусмотрена возможность включения нагревателей с помощью внешних реле малой мощности. Данный метод очень прост в реализации, т. к. не подразумевает управления мощностью нагрузки. Это значит, что регулирование температуры производится «в лоб», без использования ПИД регулятора. Но при этом накапливается большая ошибка регулирования (перегрев, потом остывание). Это заказчика устраивало. Но была и другая проблема. В модуле DS1102 – нет реле. Зато реле есть в «модифицированном» устройстве Device Server — DS1014. Данная модель имеет не только реле, но и аналоговые входы, встроенный GPRS и WiFi.
Немного отвлекусь. На самом деле устройства Device Server от Tibbo основаны на так называемых embedded модулях, о которых я расскажу в последующих статьях. Эти модули мы можем рассматривать как программируемые микроконтроллеры. Используя embedded в конструктиве с COM портами — получаем преобразователь интерфейсов. Но стоит добавить на плату АЦП, ЦАП, как мы уже получили простой модуль ввода/вывода. Именно так и была создана модель DS1014. Не сложно сделать вывод, что имея одну аппаратную основу, программы, написанные под «разное» железо Tibbo, на самом деле легко портируются между ними. Таким образом, замена одного устройства Tibbo на другое происходит безболезненно.
Заказчик согласился и на это изменение (всем бы таких заказчиков, верно?). Ну что же, существующий код переписывать не нужно. Приступаем к работе. Смотрим рассогласование температуры наружного воздуха с заданным значением и если оно больше принятой дельты принимаем решение о включении или выключении нагревателей. Давление воды в контуре упало ниже критической отметки — отключаем котлы.
Реле щелкает, в помещении тепло и комфортно. Правда реальный алгоритм еще предусматривает задержку между включением/выключением котлов во избежании «дребезга», когда температура находится в пограничном состоянии. Данные о критических событиях на объекте передаем в MySQL. Но мы еще не дали возможность пользователю оперативно задавать требуемые значения температуры в помещении. Я легко реализовал это с помощью веб-интерфейса, ведь все современные модули Tibbo имеют встроенный веб-сервер. Заодно и предусмотрел онлайн мониторинг счетчиков.
Функция html_print_value() — опросит порты MVA8 по уже известному алгоритму и отобразит значения на html странице.
Отлично, все настраивается через браузер. Заказчик доволен. Но меня уже не остановить. Как было бы удобно задавать температуру через смс! Например, возвращаясь домой после трудового дня, написать смс нашей системе, чтобы она подняла температуру в доме до 25°С. А ведь наша модель DS1014 имеет встроенный GPRS модем, который подключен по одному из 4-х последовательных портов контроллера. Поработаем немного с AT&T командами.
Как видно, в коде мы сравниваем номер телефона, с которого пришла команда с заданным. Функция gsm_get_command() — на входе получает текст смс и выделяет из нее наши команды. Например, смс с текстом «SET TEMP 25», даст команду на установку поддержания температуры в районе 25С.
А что если произошел прорыв трубопровода (резко упало давление)? В этом случае наша система уже умеет отключать нагреватели, но нужно еще и предупредить хозяина.
Теперь ответственное лицо получило оповещение о происходящем на объекте. Как видим, программирование совсем не сложное и казалось бы такие экзотические вещи, как смс управление реализуются достаточно просто и быстро. В устройстве Device Server DS1014 имеются линии аналогового ввода, так что вся система могла обойтись вообще без модуля МВА8, но он уже был на объекте и так хотел заказчик. Стоит упомянуть, что подключив программную библиотеку AggreGate Agent к написанному приложению, появляется возможность выгружать метрики в AggreGate Scada.
А с выходом более гибкой аппаратной платформы автоматизации Tibbo Project System (о которой я писал в предыдущей статье), реализация подобных систем превращается вообще в банальность и элементарный конструктор.
Получается, что оборудование от Tibbo Technology – это, конечно же, полнофункциональные классические устройства Device Server, ни в чем не уступающее конкурентам и даже превосходящее их. Но с возможностью свободного программирования и выходом аппаратной платформы TPS, разработчикам предоставили возможность выйти далеко за пределы этого функционала: создавать собственные преобразователи, аппаратные шлюзы протоколов и даже собственные ПЛК.
В сочетании с демократичной ценовой политикой, службой технической поддержки, сервисным центром и нашей помощью в консультировании при реализации проектов — клиенты получают качественный продукт в целом. Обращайтесь к нашим специалистам и мы подскажем, как наше оборудование поможет решить задачи в Ваших проектах.
Эту статью условно можно разделить на три части. В первой, речь пойдет о преобразователях интерфейсов RS232/Ethernet — что это такое и как используется.
Во второй, на примере создания шлюза ModBus ASCII_RTU/ModBus TCP продемонстрирую возможность программирования преобразователей Tibbo.
И, наконец, в третей части попробуем создать автоматическую систему управления отоплением, из немного модифицированного преобразователя интерфейсов Tibbo, с возможностью посылать команды средствами смс сообщений, веб-интерфейсом управления и выгрузкой данных в MySQL.
1. Device Server.
1.1. Что такое Device Server или немного банальностей.
Под западным понятием Serial Device Server подразумевается преобразователь интерфейсов Serial (RS232/422/485) в Ethernet. Потребность в подобных устройствах возникла по простой причине: практически любой микроконтроллер, вне зависимости от производителя, для связи с «внешним миром» использует интерфейс UART (это связанно с технологической простотой реализации данного интерфейса) на TTL или CMOS логике. Таким образом, разработчику достаточно подключить к контроллеру микросхему приемо-передатчика, чтобы получить канал передачи данных по интерфейсу RS232/485. Но последовательные интерфейсы не обеспечивают достаточных характеристик для создания современных коммуникационных систем. С другой стороны, существует развитая технология Ethernet, которая позволяет создавать локальные подсети, объединять их и организовывать каналы передачи данных между географически разнесенными точками по всему миру. Логично, что производители коммуникационного оборудования решили «объединить» последовательные интерфейсы и технологию Ethernet. Таким образом, появились аппаратные шлюзы, под названием Serial Device Server.
Преобразователи интерфейсов RS232/Ethernet от Тайваньской компании Tibbo Technology уже на протяжении 10 лет используются по всему миру. За это время инженерами компании был накоплен огромный опыт по реализации проектов с использованием данного оборудования, были решены нетривиальные задачи, а функционал устройств расширен до нового уровня, далеко выходящего за рамки «обычных» преобразователей. Данная линейка устройств имеет название Tibbo Device Server – программируемые преобразователи интерфейсов. Ключевым словом в данном определении является слово «программируемые», т. к. конечный функционал устройства полностью зависит от той прошивки, которая была создана и загружена в него.
Но начнем с простого.
1.2. Serial Over IP.
Конструктивно, устройства Tibbo Device Server (DS) представляют из себя небольшую коробочку размером с пачку сигарет. С одной стороны находится стандартный разъем (или несколько разъемов) для последовательного интерфейса, с другой — розетка для подключения витой пары по технологии Ethernet. По умолчанию, Tibbo Device Server поставляется с прошивкой “Serial Over IP”, которая позволяет передавать данные между интерфейсам RS232/485 в Ethernet.
После физической коммутации необходимо настроить параметры устройства. Для этого используется набор утилит от производителя: DS Manager – предназначен для настройки параметров устройства, VSP Manager – для настройки параметров виртуального COM порта, драйвер виртуального COM порта и несколько диагностических утилит. Я не буду подробно останавливаться на описании настроек, но обращу ваше внимание на некоторые особенности данных утилит:
- Настройка параметров устройства осуществляется прямо через локальную сеть;
- ПО работает под любой ОС Windows;
- Драйвер виртуального COM порта написан качественно и многих проблем, таких как здесь, можно избежать. Также, написана версия драйвера для Linux;
- Существует возможность кастомизации ПО.
Преобразователь интерфейсов может быть настроен на один из трех режимов. Режим клиента — это когда последовательное устройство является инициатором Ethernet соединения. Такой режим используется для пассивного мониторинга. Например, когда АТС с определенным интервалом скидывает на сервер статистику. Или сканер штрих кода передает данные в 1С. В данном режиме вы задаете ip-адрес, на который необходимо отправить данные, а виртуальный COM порт сервера прослушивает TCP/IP порт на наличие входящего потока данных.
Режим сервера — последовательное устройство отвечает на входящий запрос. Такой режим может использоваться для опроса модулей ввода/вывода, ПЛК, счетчиков и т. д.
Режим сервер/клиент — совмещает оба указанных выше варианта. В этом случае виртуальный COM порт сервера умеет как слушать входящий поток данных, так и устанавливать соединение с устройством по указанному ip адресу. Где могут использоваться подобные решения? Это множество вертикальных рынков и прикладных задач. Например:
- Опрос и мониторинг электросчетчиков в системах АСКУЭ;
- Опрос теплосчетчиков или счетчиков воды в ЖКХ;
- Сбор данных со сканеров штрих кода или RFID считывателей и передача их в 1С по виртуальному порту;
- Опрос модулей ввода/вывода;
- Удаленный мониторинг и контроль модулей ПЛК;
- Мониторинг АТС или инженерных систем здания;
- Системы пожарной безопасности или контроля доступа;
- Удаленный контроль вашего собственного микроконтроллера;
- Другими словами, преобразователи интерфейсов могу использоваться везде, где требуется удаленная работа с последовательными интерфейсами.
Многие зададут вопрос, а чем устройства Tibbo лучше аналогов (которых достаточно в данном сегменте)? Я не буду детально сравнивать технические характеристики, которые у большинства аналогичных устройств идентичны друг другу. Упомяну лишь о важных особенностях преобразователей Tibbo:
- Удобное, качественное и надежное ПО, которое работает не только под Windows, но и под Linux;
- Надежный драйвер виртуального COM порта;
- Возможность создания автономных систем (устройство – DS – DS – устройство), без участия ПК;
- Возможность настройки преобразователя через Веб-интерфейс управления;
- Как опция, возможность использования WiFi сети 802.11b/g. Таким образом, мы можем передавать данные с последовательного порта средствами беспроводной передачи данных;
- Как опция, использование технологии Power over Ethernet;
- Защищенная линейка оборудования DS10xx с опторазвязкой последовательных портов, сертификатом защиты IP68 и возможностью передачи данных по GPRS;
- Поддержка протоколов UDP, TCP, ARP, ICMP (PING), DHCP, PPPoE, LCP и HTTP;
- Возможность настройки через Telnet;
- Прямое управление ADSL модемов;
- Реализована возможность мультиканальной работы последовательного интерфейса (через один разъем DB9 можно подключать до 3 устройств с интерфейсом RS232);
- Легкое подключение преобразователей к системе AggreGate Scada/HMI;
- Нельзя не упомянуть о ценовой политике, которая выгодно отличается от аналогов.
Но главное отличие от конкурентов — преобразователи Tibbo являются программируемыми! Что если указанного функционала не хватает и нужно что-то особенное? Давайте разберемся, как этого можно достигнуть и как можно раскрыть полный функционал Device Server от Tibbo Technology.
2. Программирование Device Server или создаем ModBus шлюз.
Что если на объекте установлена Scada система, которая опрашивает устройства по протоколу ModBus TCP. А нам требуется опросить устройство с протоколом ModBus RTU и последовательным каналом RS232 на борту. Подключив обычный преобразователь интерфейсов RS232, получим выход в локальную сеть и даже Интернет, но Scada не увидит никаких данных без реализации протокола ModBus.
Вот здесь и приходит на помощь главная особенность преобразователей Tibbo — возможность программирования.
Программы кодируются на событийном объектно-ориентированном языке Tibbo Basic. Кратко я об этом писал в статье о Tibbo Project System. На данный момент готов компилятор для языка «С» и в скором времени состоится его релиз. Таким образом, вы сможете выбирать язык программирования — функциональный и глубокий «С» или более простой, легкий в понимании Basic.
Среда программирования Tibbo IDE распространяется бесплатно. Для отладки программ и прошивки не требуется никаких программаторов, все осуществляется прямо через локальную сеть Ethernet, включая пошаговый режим прохода программы и точки останова.
Итак, для реализации нашей задачи (опрос устройства с ModBus RTU), нам требуется реализовать протокол ModBus для оборудования Tibbo. К счастью, протокол уже написан и находится в открытом доступе. Нам достаточно скачать его с сайта, подключить к проекту, скомпилировать, прошить устройство и мы получаем шлюз ModBus RTU в ModBus TCP.
Вот как выглядит проброс данных в исходном коде, после подключения библиотек.
Исходный код:
sub on_ser_data_arrival() 'Системное событие, возникает при появлении данных на последовательном интерфейсе.
dim x as string
#if modbus_serial_mode = 0 'ASCII режим
x = ascii_to_tcp(ser.getdata(255)) 'Преобразуем данные из ASCII в tcp
#else 'RTU режим
x = rtu_to_tcp(ser.getdata(255)) 'Преобразуем данные из RTU в tcp
#endif
sock.num = 0
sock.setdata(x) 'подготавливаем данные для передачи по последовательному интерфейсу
sock.send 'отправляем данные.
end sub
'--------------------------------------------------------------------
sub on_sock_data_arrival() 'Системное событие, возникает при появлении данных на сокете.
dim x as string
#if modbus_serial_mode = 0 'ASCII режим
x = tcp_to_ascii(sock.getdata(255)) 'функция преобразует данные в формат ASCII
#else 'RTU режим
x = tcp_to_rtu(sock.getdata(255)) 'Функция преобразует данные в формат RTU
#endif
ser.num = 0
ser.setdata(x) 'подготавливаем данные для передачи по последовательному интерфейсу
ser.send 'отправляем данные
end sub
'настроим ip адреса, сокет и последовательный порт
sub on_sys_init()
'Системное событие, возникает при подачи питания на устройство
net.ip = "192.168.1.222"
net.netmask = "255.255.255.0"
net.gatewayip = "192.168.1.1"
'setup the Ethernet socket
sock.num = 0
sock.protocol = PL_SOCK_PROTOCOL_TCP
sock.inconmode = PL_SOCK_INCONMODE_ANY_IP_ANY_PORT
sock.reconmode = PL_SOCK_RECONMODE_1
sock.localportlist = "502"
sock.connectiontout=50
sock.rxbuffrq(2)
sock.txbuffrq(2)
'setup the serial port
ser.num = 0
ser.parity = PL_SER_PR_NONE
ser.bits = PL_SER_BB_8
ser.flowcontrol = DISABLED
ser.baudrate = ser.div9600
ser.interface = PL_SER_SI_FULLDUPLEX
ser.interchardelay = 5
ser.rxbuffrq(3)
ser.txbuffrq(2)
sys.buffalloc
ser.enabled = YES
end sub
Расширим задачу. Последовательное устройство вообще не поддерживает протокол ModBus, а так хочется подключить его к Scada системе. Тогда запрограммируем опрос необходимых метрик устройства по обычному интерфейсу RS232, берем код ModBus TCP и получаем аппаратный драйвер специально для вашего устройства.
Можно и дальше расширять задачу — необходимо резервное копирование данных в случае обрыва связи? Используем встроенную флеш-память на 1 Мбайт и храним данные автономно, до восстановления связи. Нужна настройка через веб-интерфейс? Программируем встроенный веб-сервер и получаем заданный функционал.
Таким образом, вы можете реализовать любой протокол, создавая собственные аппаратные драйвера устройств и даже больше. Вы можете программировать логику, получая свой собственный маленький ПЛК.
3. Немного практики или управление отоплением в лоб.
Однажды мне попалась довольно интересная задача. В частном доме установлена система отопления — два электрических водонагревательных котла. На выходе котла и в обратной ветви трубопровода установлены датчики температуры воды, также в системе присутствуют датчик избыточного давления и датчик температуры наружного воздуха. Все датчики были заведены на модуль аналогового ввода МВА8 (ОВЕН), который «общается с миром» через интерфейс RS485. Задача — удаленный мониторинг показаний датчиков. В идеале, система должна записывать значения в базу данных MySQL для дальнейшего отображения информации на личном сайте заказчика. Я выбрал устройство DS1102.
Первое, что нужно было сделать — реализовать протокол передачи данных для модуля МВА8. Протокол достаточно простой и на кодирование было потрачено несколько часов, в результате была получена пара полезных функций для работы с модулем аналогового ввода, среди которых get_data_sensor(). Следующим шагом была реализация протокола MySql. Тут я потратил чуть больше времени. В результате и эта задача была решена за несколько часов. Готовая библиотека MySql опубликована на сайте производителя.
Итак, DS1102 теперь умеет обращаться к базе данных MySql, умеет опрашивать МВА8, пора заняться простейшей логикой — опрашивать датчики и записывать значения в базу данных.
Исходный код:
sub on_sys_timer 'системный таймер, событие возникает каждые 0.5 сек.
if sys.timercount>delay_get_data then ' считаем. если прошло больше времени, чем задано пользователем, делаем опрос портов МВА8
ser.num=0 'выбор одного из последовательных каналов
get_data_sensor() 'Функция, которая пошлет запрос в МВА8, чтобы получить значения датчиков
end if
End sub
sub on_ser_data_arrival()
dim buff, temp as string
dim value as packet
select case ser.num
Case 0:
'-----Извлечение данных и выполнение необходимых операций-----
mva8=incoming_data(ser.getdata(ser.rxlen)) 'функция расшифрует данные МВА8 и передаст их переменной Value (тип enum) в виде значений датчиков на каждом порту.
….
End select
mysql_connect(“login”,”password”,”database_name”) 'подключаемся к базе данных и выполняем SQL запрос на добавление строки
sql_query("INSERT INTO tbl_Sensor VALUES ("+
chr(34)+mva8.temperature_in+chr(34)+", "+
chr(34)+mva8.temperature_out+chr(34)+", "+
chr(34)+mva8.temperature_air+chr(34)+", "+
chr(34)+mva8.pressure+chr(34)+", "+
chr(34)+device_name+chr(34)+", "+
"NOW(),"+
chr(34)+chr(34)+")",0)
sql_disconnect()
End sub
Все работает, данные успешно передаются в таблицу MySql. Заказчик доволен и уже готов был отметить успешную реализацию, как вдруг спросил: «А можно удаленно управлять температурой в помещении?». Ну что же, раз хочется, значит сделаем.
Управление котлами с помощью реле.
В цепи питания котлов производителем была предусмотрена возможность включения нагревателей с помощью внешних реле малой мощности. Данный метод очень прост в реализации, т. к. не подразумевает управления мощностью нагрузки. Это значит, что регулирование температуры производится «в лоб», без использования ПИД регулятора. Но при этом накапливается большая ошибка регулирования (перегрев, потом остывание). Это заказчика устраивало. Но была и другая проблема. В модуле DS1102 – нет реле. Зато реле есть в «модифицированном» устройстве Device Server — DS1014. Данная модель имеет не только реле, но и аналоговые входы, встроенный GPRS и WiFi.
Немного отвлекусь. На самом деле устройства Device Server от Tibbo основаны на так называемых embedded модулях, о которых я расскажу в последующих статьях. Эти модули мы можем рассматривать как программируемые микроконтроллеры. Используя embedded в конструктиве с COM портами — получаем преобразователь интерфейсов. Но стоит добавить на плату АЦП, ЦАП, как мы уже получили простой модуль ввода/вывода. Именно так и была создана модель DS1014. Не сложно сделать вывод, что имея одну аппаратную основу, программы, написанные под «разное» железо Tibbo, на самом деле легко портируются между ними. Таким образом, замена одного устройства Tibbo на другое происходит безболезненно.
Заказчик согласился и на это изменение (всем бы таких заказчиков, верно?). Ну что же, существующий код переписывать не нужно. Приступаем к работе. Смотрим рассогласование температуры наружного воздуха с заданным значением и если оно больше принятой дельты принимаем решение о включении или выключении нагревателей. Давление воды в контуре упало ниже критической отметки — отключаем котлы.
Исходный код:
sub on_sys_timer
…...
If control = true then 'если контроль котлами разрешен, выполняем необходимые действия, если запрещен, ничего не делаем (котлы выключены)
If mva8.temperature_air>temperature_set+delta then boiler(on)
If mva8.temperature_air<temperature_set-delta then boiler_on(off)
End if
If mva8.pressure<pressure_min then 'Если давление упало до критической отметки, выключаем котлы и запрещаем управление ими.
boiler(off)
Control = false
Else
Control = true
End if
End sub
public sub boiler (on_off as string[3]) 'Функция управления котлами, включает и выключает 2 реле, подключенных к котлам.
select case on_off
case “on”:
io.num=PL_IO_NUM_13_TX2
io.state=LOW
io.enabled=Yes
io.num=PL_IO_NUM_3
io.state=LOW
io.enabled=Yes
case “off”:
io.num=PL_IO_NUM_13_TX2
io.enabled=NO
io.num=PL_IO_NUM_3
io.enabled=NO
end select
end sub
Реле щелкает, в помещении тепло и комфортно. Правда реальный алгоритм еще предусматривает задержку между включением/выключением котлов во избежании «дребезга», когда температура находится в пограничном состоянии. Данные о критических событиях на объекте передаем в MySQL. Но мы еще не дали возможность пользователю оперативно задавать требуемые значения температуры в помещении. Я легко реализовал это с помощью веб-интерфейса, ведь все современные модули Tibbo имеют встроенный веб-сервер. Заодно и предусмотрел онлайн мониторинг счетчиков.
Исходный код:
<h3> Онлайн мониторинг</h3>
<table width=80% align=center>
<tr><td>
<br>
<table width=100% align=center border="1" cellspacing="1" cellpadding="2" >
<form action="online.html?" method="get">
<? html_print_session?>
<tr>
<td width=33%><font color = <?sock.setdata(FONT_COLOR_1) sock.send?>><b>Порт</b></td>
<td width=33%><font color = <?sock.setdata(FONT_COLOR_1) sock.send?>><b>Значение</b></td>
</tr>
<?
if html_login_state = LOGIN then
html_print_value()
end if
?>
</form>
</table>
</td></tr>
</table>
Функция html_print_value() — опросит порты MVA8 по уже известному алгоритму и отобразит значения на html странице.
Смс управление
Отлично, все настраивается через браузер. Заказчик доволен. Но меня уже не остановить. Как было бы удобно задавать температуру через смс! Например, возвращаясь домой после трудового дня, написать смс нашей системе, чтобы она подняла температуру в доме до 25°С. А ведь наша модель DS1014 имеет встроенный GPRS модем, который подключен по одному из 4-х последовательных портов контроллера. Поработаем немного с AT&T командами.
Исходный код:
sub on_ser_data_arrival()
…
Select case ser.num
…
case 1:
'-----Считываем буфер данных и переходим на функцию извлечения gsm команды-----
gsm_extract(ser.getdata(ser.rxbuffsize))
...
end select
End sub
public sub gsm_extract(buff as string)
…
select case prefix
…
case "+CMGR":
i=instr(1,buff,chr(44),1)
j=instr(1,buff,chr(44),2)
cmpphone=mid(buff,i+2,j-i-3)
if cmpphone=phone then
j=instr(9,buff,chr(13)+chr(10),1)
data=mid(buff,j+2,len_buf-j-2-3)
gsm_get_command(data) 'функция выделит из строки данных команду.
end if
in ="AT+CMGD="+num+chr(13)
if val(num)>10 then in="AT+CMGDA="+chr(34)+"DEL ALL"+chr(34)+chr(13) 'если в памяти накопилось более 10 смс удаляем их, чтобы не переполнить SIM карту.
ser.num=ser_gsm
ser.setdata(in)
ser.send
case "error":
….
end select
End sub
Как видно, в коде мы сравниваем номер телефона, с которого пришла команда с заданным. Функция gsm_get_command() — на входе получает текст смс и выделяет из нее наши команды. Например, смс с текстом «SET TEMP 25», даст команду на установку поддержания температуры в районе 25С.А что если произошел прорыв трубопровода (резко упало давление)? В этом случае наша система уже умеет отключать нагреватели, но нужно еще и предупредить хозяина.
Исходный код:
sub on_sys_timer
…...
If mva8.pressure<pressure_min then
boiler(off)
Control = false
gsm_send_sms("AT+CMGS=","CRITICAL PRESSURE. BOILER OFF.")
...
End sub
public sub gsm_send_sms(command as string,data as string)
dim gprs_data as string
gprs_data =command+chr(34)+phone+chr(34)+chr(13)+data+chr(26)+chr(13) 'Подготавливаем команду для модема, текст сообщения и номер телефона
ser.num=1
ser.setdata(gprs_data) 'отправляем данные в модем.
ser.send
end sub
Теперь ответственное лицо получило оповещение о происходящем на объекте. Как видим, программирование совсем не сложное и казалось бы такие экзотические вещи, как смс управление реализуются достаточно просто и быстро. В устройстве Device Server DS1014 имеются линии аналогового ввода, так что вся система могла обойтись вообще без модуля МВА8, но он уже был на объекте и так хотел заказчик. Стоит упомянуть, что подключив программную библиотеку AggreGate Agent к написанному приложению, появляется возможность выгружать метрики в AggreGate Scada.
А с выходом более гибкой аппаратной платформы автоматизации Tibbo Project System (о которой я писал в предыдущей статье), реализация подобных систем превращается вообще в банальность и элементарный конструктор.
Получается, что оборудование от Tibbo Technology – это, конечно же, полнофункциональные классические устройства Device Server, ни в чем не уступающее конкурентам и даже превосходящее их. Но с возможностью свободного программирования и выходом аппаратной платформы TPS, разработчикам предоставили возможность выйти далеко за пределы этого функционала: создавать собственные преобразователи, аппаратные шлюзы протоколов и даже собственные ПЛК.
В сочетании с демократичной ценовой политикой, службой технической поддержки, сервисным центром и нашей помощью в консультировании при реализации проектов — клиенты получают качественный продукт в целом. Обращайтесь к нашим специалистам и мы подскажем, как наше оборудование поможет решить задачи в Ваших проектах.