Официальный сайт компании Arduino по адресу arduino.cc
C++ мастер ModBus RTU over TCP
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
Пт, 20/10/2017 - 20:42
Нужен мастер ModBus RTU over TCP для UBUNTU server, опрос слейвов и отправка в SQL базу. Язык с++, VB либо другой, главное надежность работы
libmodbus чем-то не подходит?
VB на ардуине наврядли запустить получится.
libmodbus чем-то не подходит? -> тяму не хватет на нее((
VB на ардуине наврядли запустить получится. -> мастер на ubuntu сервер ставить, и он уже опрашивает слейвы через USR-TCP232-410s
Ну, допустим, есть modbus-cli - думаю, что проще уж некуда. Если мониторинг рассматривать (зачем иначе вам SQL), то Zabbix + modbus module.
Через SQL идет работа внутреннего сайта по управлению, мониторингу, отображение текущей обстановки
ибо локальный сайт на php/html более проще администрировать и подзатачивать под текущие потребности
И не нужно делать приложение типа Skada и т.п.
Просто лично мне кажется, что ардуина тут явный оверкилл и лишнее звено. Если ошибаюсь, то меня немедленно поправят.
Просто лично мне кажется, что ардуина тут явный оверкилл и лишнее звено. Если ошибаюсь, то меня немедленно поправят.
ардуино стоят как слейвы , которые считываю датчики, дергают ногами. можно конечно промышленных датчиков напихать - но цена вопроса космос((
https://yadi.sk/i/nnoB3uUw3Nx6LP
Теперь стало понятней - вам нужно сделать голубую стрелочку с дымком. Осталось рассказать, как зовут преобразователя интерфейсов. Я бы вам, быть может и хотел помочь, но что-то медленно соображаю чем фиолетовый квадратик может взаимодействовать с голубой стрелочкой (т.е., я, конечно, подозреваю, что этот квадратик транслирует TCP в RTU и обратно, но хотелось бы знать наверняка).
Вот тот самый "квадратик" http://www.usriot.com/p/serial-to-ethernet-modbus-converter/
Через ModBus Poll через "квадратик" c настройками https://yadi.sk/i/6qm7N42r3Nx98S все отлично работает, слейв читает отлично, тестил сутки ни одной ошибки
у квадратика даже вебморда есть https://yadi.sk/i/wu9V42V63Nx9P3
Теперича вроде все понятно. Можно попробовать изобразить стрелочку с дымком. Как с вами связаться?
напишите на pwal1969@mail.ru
А вот я не понял... Вы хотите получать постоянный поток данных со слейвов ? То есть нужно звено которое постоянно опрашивает слейвы и пихает их данные на сервер? Пихает через как, через последовательный порт ? Или как то еще ?
А вот я не понял... Вы хотите получать постоянный поток данных со слейвов ? То есть нужно звено которое постоянно опрашивает слейвы и пихает их данные на сервер? Пихает через как, через последовательный порт ? Или как то еще ?
мастер опрашивает постоянно слейвы (собирает данные) пихает в sql и берет данные что где дернуть какую ногу , значения для диапазонов и т.п. из sql
т.е. запросил данный сложил в базу взял из базы отдал слейву в регистры
а как и что делать (включить или т.п. ) это уже юзер будет делать , вернее php
мастер то на серваке должен как служба работать
То есть вам нужна не ардуино, а демон на убунте ?
То есть вам нужна не ардуино, а демон на убунте ?
да, я же в блок схеме нарисовал что и как
слейвы это ардуинки на atmege328
Как по вашему внешнее устройство должно засунуть данные в вашу сиквельную базу которая вертится на сервере ? Или у вас уже есть служба которая слушает порт и складвает в базу входящие через порт данные, и отдает по запросу данные на это внешнее устройство?
Как по вашему внешнее устройство должно засунуть данные в вашу сиквельную базу которая вертится на сервере ? Или у вас уже есть служба которая слушает порт и складвает в базу входящие через порт данные, и отдает по запросу данные на это внешнее устройство?
как вы писали ранее - демон мастер опрашивает слейвы и складывает в sql забирает оттуда данные и отправляет в регистры слейвов, слейвы на основании данных от мастера уже сами делаю что надо
пример: мастер взял данные от слейва1 (температуру) сложил в базу - взял с базы пределы температуры верний и нижний - отдал слейву, слейв получил сравнил с текущей и принимает решение включить или отключить например вентилятор
отсюда и применение в качестве слейвов ардинки, а не тупо пром датчики с RS485
Блин... мы на разных языках разговариваем. Смотрите. Сиквел это бвза двнных, сами данные хранятся на сервере, где работает служба сиквельная, которая по сети отвечает на запросы опраделенного формата на определенный порт и складывет принятые данные в бвзу или делает оттуда выборки, которве по сети отдает вопрашающему. У вас стоит гейт, который позволяет по эзернету общаться с модбас устройствами (слейвами), что бы получить данные от них им нужно, что бы мастер направил им запрос. У вас мастера нет. Слейвы есть, ереда передачи есть, а мастера нет. Вы хотите некое устройство, которое бвло бы мастером для вашей сети слейвов, это ясно, оно должно дергать слейвы и собирать с них данные. Что дальше оно должно делать с этими данными ? Вы хотите, что бы оно , как полноценный SQL клиент работало с вашей базой по TCP ?
Вы хотите, что бы оно , как полноценный SQL клиент работало с вашей базой по TCP ?
увы, с языком у меня проблема)
Если есть желание - давайте голосом поговорим. напишите Ваш вацап или скайп на pwal1969@mail.ru
Голосовыми службами не пользуюсь. Для этого есть телефон, сори. Телефон даю потенциальному клиенту, только поняв его желания. На данный момент я не понимаю, что вы хотите.
По моему мнению, есть два варианта. В вашем случае нужна программа которая будет в фоне на убунте работать мастером и собирать данные со слейвов и пихать их в базу sql. За такое решение не возьмусь,
Если же вы очень хотите ардуино, то тогда гейт Модбас-эзернет скорее лишний. Нужна ардуино, которая будет мастером в сети модбас и по эзернету будет пизхать данные на ваш сервер. Но я опять не понимаю... SQL это виндоус, на убунте чистого сиквела нет, а значит может не быть нужных, для запихивания данных, служб.
В общем, я устал объяснять. Если не найдете исполнителя, то напишите brokly(at)mail.ru, но только если не найдете :)
MySql нормально работает на убунте
ардуина мастер не пойдет по одной причине, что у нее очень не стабильная работа в связке TCP, у меня сейчас работает проект на w5500 шилдах - но это не очень устойчивая система, т.к. проблема с мак адресами - они не от железа а программно ставятся и отсюда порой конфликты и коллизии появляются- который в локалке отловить практически не реально. ModBus более надежный в этом.
на STM контроллеры переходить тоже не посилам, ибо там нужно очень прилично знать с++
А куда на линупсе sql делся - уже из реп выкинули что ли? )) Вот так уйдешь на выходные, а потом SQL пропадает....
Да перестаньте, все нормально работает. Да и знание си при переходе на STM это странный довод.
По поводу arduino и w5500... А в вашей связке вы уходите от эзернета ? Если так, то мне вообще нихрена не понятно.
Все равно вы будете подключаться к серверу через эзернет... или нет ?
Если честно, мне стало еще непонятнее :( Я не вижу синей стрелочки с дымком (на картинке вижу, в жизни не понимаю). Вот концы стрелочки это стык, другими словами физический интерфейс, что за интерфейс ?
эзернет используется от унбунты посредством мастера для работы с RS485 по модбасу по tcp
для стм нужно писать самому библиотеки, что бы работало все норм. использования гугла и взятие билиотек из гагахаба - не очень хороший вариант
Я туповат... правда не понял... Раз sadman41 Вас понял, думаю он поможет. Я считаю себя не в праве и далее мучать вас.
я щас один глупый вещь скажу, только вы не обижайтесь. Если я правильно понял, есть некое количество обвешанных датчиками (и всякими исполнительными приблудами:вентиляторы, нагреватели, блабла) ардуин, которые отправляют серверу некие данные с некоей периодичностью, по которым оный сервер дает им команды на включение\отключение этих самых вертиляторов и прочих штуковин.
Самим ардуинам на местах мы такое решение доверить не можем, (допустим, всю картину боя видно только серверу), распределить задачу по скудненьким мозгам ардуин - тоже (они для того не предназначены вроде еще пока). Следвательно, решение принимается "в центре" и предается назад "на места" ардуинам, как приказ на исполнение.
Все хозяйство соединено проводами (это существенный момент, потому как такую систему можно и допустим по целой стране распределить, на gprs, например) и относительно компактно.
Это я к тому, что если нет особой проблемы - один кабель тянуть от каждой из ардуин или можно и два - то тогда гораздо прощщще ардуины только для сбора телеметрии задействовать, а команды на исполнение к вертиляторам уже непосредственно от сервака направлять (минуя ардуины и не загружая их этой задачей вапще). Один кабель, там юсб хаб, на нем куча юсб-релюх. Все тогда на центральном компе наглядно на экране, хошь в ручную нажимай, хошь - наблюдай как автоматика сама щелкает. Понавесить можно массу таким образом управляемых "вертиляторов". Надежность чумовая...
впрочем это я так, в порядке бреда)))
я щас один глупый вещь скажу, только вы не обижайтесь. Если я правильно понял, есть некое количество обвешанных датчиками (и всякими исполнительными приблудами:вентиляторы, нагреватели, блабла) ардуин, которые отправляют серверу некие данные с некоей периодичностью, по которым оный сервер дает им команды на включение\отключение этих самых вертиляторов и прочих штуковин.
Самим ардуинам на местах мы такое решение доверить не можем, (допустим, всю картину боя видно только серверу), распределить задачу по скудненьким мозгам ардуин - тоже (они для того не предназначены вроде еще пока). Следвательно, решение принимается "в центре" и предается назад "на места" ардуинам, как приказ на исполнение.
Все хозяйство соединено проводами (это существенный момент, потому как такую систему можно и допустим по целой стране распределить, на gprs, например) и относительно компактно.
Это я к тому, что если нет особой проблемы - один кабель тянуть от каждой из ардуин или можно и два - то тогда гораздо прощщще ардуины только для сбора телеметрии задействовать, а команды на исполнение к вертиляторам уже непосредственно от сервака направлять (минуя ардуины и не загружая их этой задачей вапще). Один кабель, там юсб хаб, на нем куча юсб-релюх. Все тогда на центральном компе наглядно на экране, хошь в ручную нажимай, хошь - наблюдай как автоматика сама щелкает. Понавесить можно массу таким образом управляемых "вертиляторов". Надежность чумовая...
впрочем это я так, в порядке бреда)))
Принцип действия Вами описан очень точно, если бы не одно но- рухнула сеть , на какоето время и все все остановилось. Ибо центр юстасам не фига не может выдать. В моем случае - даже если сервак на обслуживание и т.п. то адруинки имея установочные данные - тупо молотят по циклу и все(главное их не сильно загружать логикой) 1 тех процесс одна атмега328 . А вот датчики нифига. не проводная связь не подходит, ибо эл.двигатели дают помехи и т.п.
+RS485 может работать до 1,2км по проводам- у меня правда не такие большие растояния, метров от 10 до 50 uart тут не прокатит однозначно
Я туповат... правда не понял... Раз sadman41 Вас понял, думаю он поможет. Я считаю себя не в праве и далее мучать вас.
Вы не мучаете)) Просто у Вас своя точка зрения и алгоритм
Все тогда на центральном компе наглядно на экране, хошь в ручную нажимай, хошь - наблюдай как автоматика сама щелкает. Понавесить можно массу таким образом управляемых "вертиляторов". Надежность чумовая...
Есть золотое правило жизни, крутость сисадмина падает до нуля когда появляется бухой электрик)
Принцип действия Вами описан очень точно, если бы не одно но- рухнула сеть , на какоето время и все все остановилось. Ибо центр юстасам не фига не может выдать. В моем случае - даже если сервак на обслуживание и т.п. то адруинки имея установочные данные - тупо молотят по циклу и все(главное их не сильно загружать логикой) 1 тех процесс одна атмега328 . А вот датчики нифига. не проводная связь не подходит, ибо эл.двигатели дают помехи и т.п.
+RS485 может работать до 1,2км по проводам- у меня правда не такие большие растояния, метров от 10 до 50 uart тут не прокатит однозначно
Тут конечно есть и еще вопросы. Например, насколько критичны могут быть задержки реакции сервака на данные телеметрии, а также, как долго система сможет молотить в описанном вами случае на старых (последних прижизенных) настройках, которые сохранились в мозгах ардуин.
Описанная сеть (если она выполена на проверенных на большой статистике компонентах) может "рухнуть" только на период самоперезагрузки компа. А если ваше приложение занесено на нем в автозапуск - то очнувшись, он сттанет снова немедленно молотить. Это пара минут максимум, весь процесс.Также прекрасно и полезно, если управляет всем делом простенький комп, которым ничем другим вообще не занят и никто даже случайно чото там не может нажать не так. Еще лучше вообще не под обыной виндой, а по версией чтото типо pos ready. Она тупая, легкая лишена лишнего и конфигурируется под задачу. Всякие терминалы - это на ней молотят.
Если действительно есть необхдимость в надежности и автономности - тогда неплохо и програмный и внешний., аппаратный ватчдог реализовать (на базе тойже ардуины) которая будет постоянно отсдеживать что комп жив и презагрузит, если не получит пинг вовремя. Ну, а уж ежели не сможет его реанимировать - то отошлет "админу" или "эелектрику" смс-ку. Что, мол, беги! Зверюшки (или кто там) могут окочурится. На юсб кстати на такие расстояния работает.
Дело в том, что есть в системе узлы при перезагрузке по вачдогу ардуинки - силовая часть кратковременно отключется тоже, соотвественно мигает свет и т.п. в помещение- что однозначно плохо. пока не обкатывал, но думаю что 74ch595 должен помочь в этом, при условии что на него питание идет отдельно от ардуинки(только GND одна) И соответсвенно usb релюхи не прокатывают в этом варианте
Тянуть отдельные провода к каждому узлу(получается на манер звезды) тоже не практично, так что rs485 самое то для реализации физического контакта, ну а модбас програмного
Дело в том, что есть в системе узлы при перезагрузке по вачдогу ардуинки - силовая часть кратковременно отключется тоже, соотвественно мигает свет и т.п. в помещение- что однозначно плохо. пока не обкатывал, но думаю что 74ch595 должен помочь в этом, при условии что на него питание идет отдельно от ардуинки(только GND одна) И соответсвенно usb релюхи не прокатывают в этом варианте
Не думаю, что оно вам поможет. По факту - коряво написаный слейв. В конце концов можно так написать, что никакая перезагрузка не будет влиять на нормальную работу.
не коряво написанный слейв, а корявая библиотека эзернет шилда
не коряво написанный слейв, а корявая библиотека эзернет шилда
А библиотеку поправить ? Ну да ладно, это уже офтоп.
Тупо и не стабильно
не коряво написанный слейв, а корявая библиотека эзернет шилда
А библиотеку поправить ? Ну да ладно, это уже офтоп.
Если править библиотеку , надо хорошо с++ знать, а с этим проблемы - отсюда и поиск решения и обращение на форуме
Ну вы же сами так написали, что в случае обрыва связи , вместо попытки ее восстановить , вы вешаете девайс в бесконечном цикле.
В общем. Вым нужно устройство с одной стороны которого RS485 к которому подключены модбас клиенты, на втором конце эзернет, в одной сети с вашим сервером на котором крутится MySQL. Устройство является модбас мастером и в цикле опрашивает клиентов. Полученные данные сиквельными запросами инжектирует данные в базу MySQL, дальше вы их сами обрабатываете. Точно так же в цикле устройство запрашивает из базы выборку содержащую данные которые необходимо отправить на тот или иной слейв, если такие находятся, то устройство командуем соответствующим слейвом.
Ваш гейт модбас-эзернет - убирайте из этой системы, он тут не нужен. А вот опторазвязка на мод басе, просто необходима. Но это уже вопрос схемотехники.
Вообще, по большому счету, тут нужна скада.
Девайс работает в штатном режиме - у него есть установочные данные он их и обрабатывает. а уже на странице управления контролируется время обновления данных- если нет данных более ххминут то тревога бьется
В общем. Вым нужно устройство с одной стороны которого RS485 к которому подключены модбас клиенты, на втором конце эзернет, в одной сети с вашим сервером на котором крутится MySQL. Устройство является модбас мастером и в цикле опрашивает клиентов. Полученные данные сиквельными запросами инжектирует данные в базу MySQL, дальше вы их сами обрабатываете. Точно так же в цикле устройство запрашивает из базы выборку содержащую данные которые необходимо отправить на тот или иной слейв, если такие находятся, то устройство командуем соответствующим слейвом.
Ваш гейт модбас-эзернет - убирайте из этой системы, он тут не нужен. А вот опторазвязка на мод басе, просто необходима. Но это уже вопрос схемотехники.
Вообще, по большому счету, тут нужна скада.
гейт модбас-эзернет вот он то как раз и нужен для прозрачной трансляции протокола от мастера к слейвам по rs485
а скада тут не нужна, по причине ее громозкости , да там все красиво , но что то дельное запилить под свои хотелки - очень сложно
Блииииин... ГДЕ У ВАС MODBUS МАСТЕР ?
Читайте выше- я как раз и искал исполнителя , для создания мастера на с++ или т.п.
Спасибо, поржал. Похоже на разговор глухого с немым.
Мастера который втыкается в эзернет, ModBus TCP , правильно ? Вы устройство с одним эзернет входом, которое Мастер МодБас TCP + SQL инжектор ?
Сами же говорите, что эзернет - на ардуино дикий глюк, но при этом желаете строить на нем две службы в одной ардуине :)
хм, на блок схеме все указанно же
Мастера который втыкается в эзернет, ModBus TCP , правильно ? Вы устройство с одним эзернет входом, которое Мастер МодБас TCP + SQL инжектор ?
Сами же говорите, что эзернет - на ардуино дикий глюк, но при этом желаете строить на нем две службы в одной ардуине :)
Встречный вопрос - каким образом Вы бы соеденили сом порт или эзернет порт сервера на ubunte с RS485 ???
Каким образом это можно реализовать https://yadi.sk/i/zNNTxX9p3NxnFY
Да ничего там не указано. Где там расписаны интерфейсы, протоколы, спсособ взаимодействия, настройка ? Что там физическое, что там логическое? Это просто картинка, без пояснений.
Смотрите ЛОГИЧЕСКИ, требуемое вам устройство имеет ДВА СТЫКА с гейтом и сервером. ФИЗИЧЕСКИ - один эзернет. У вас на картинке что !?
Теперь по делу. То что вы хотите - возможо. Но это настоящая работа, которая потребует еще и описание способа взаимодействия. Например совсем не понятно как этот мастер будет настраиваться и таких пробелов дохрена.
Способ взаимодействия -отправка в порт эзернета пакета в адрес usr 410s с данными модбаса, т.е. наложить модбас на tcp а девайс уже в чистом виде отдаст пакет в сеть модбаса, пото примет наложит на tcp и отправит мастеру ответ слейва
Встречный вопрос - каким образом Вы бы соеденили сом порт или эзернет порт сервера на ubunte с RS485 ???
Каким образом это можно реализовать https://yadi.sk/i/zNNTxX9p3NxnFY
Com - элементарным трехкопеечным конвертером RS232-RS485
ModBas TCP - конвертером посложнее, таким как у вас. Только в вашем случае, все равно нужно некое устройство, которое уже само по себе может быть таким конвертером.