ardsoft
Продукты => arOPC сервер => Тема начата: JonyBest от 29.07.2020, 22:59:09 pm
-
Доброго времени суток!
Есть у кого опыт настройки или документация по настройке arOPC для работы по протоколу MQTT? Не могу разобраться. В конфигурации MQTT настраиваю- здесь проблем нет.
Какой контроллер надо выбрать из списка?
Если выбираю контролер "Симуляция", добавляю Теги, показывает только значения созданного последним Тега...
-
Добрый день.
Если вы не работаете с физическим оборудованием или нет необходимости данные с физического оборудования транслировать в MQTT брокер, надо выбирать контроллер "Симуляция". Обмен данными по MQTT настраивается в каждом теге индивидуально.
Подробнее о настройке описано в главе 4 инструкции. Разворачивается она при установке OPC сервера и доступна в меню "Пуск - Все программы - arOPC".
Если там что то непонятно, пришлите конфигурацию которую вы пытаетесь собрать, я подскажу где ошибка и что дальше делать.
Айрат.
-
Спасибо за ответ! Вот файл конфигурации - 1.cfx Что происходит - фото м1, хотя данные сыпятся раз в сек
И еще вопросик - топик "key" - если включить и прием и отправку(файл конфигурации - 2.cfx), при отправке сообщения - забивает эфир постоянным отправлением уже отправленного значения фото м2
Прошу помощь понять где допускаю ошибку...
-
Добрый день!
Да, в OPC сервер закралось несколько ошибок. Буду заниматься исправлением.
Пока могу дать следующие рекомендации:
1. Переключить QoS у тегов в 0 или 2.
2. То что постоянно сыпятся сообщения, это надо поправить настройках подключения к MQTT брокеру, параметр "Период публикации". Если вам не нужны повторяющиеся сообщения выставьте его в 0. Тогда сообщения будут отправляться только по изменению.
Айрат
-
Мне крайне не удобно, но по пункту 1, с переключением QoS у тегов в 0 или 2 проблема не уходит. Ошибка та же - показывает только последнее значение. При чем если удалить последнее, то отображает то что было предпоследним, а стало последним.Сторонним клиентом смотрю - данные сыпятся.
2. Тут всё четко!
-
Добрый день!
Какой MQTT брокер используете в своей работе?
Айрат
-
Mosquitto-1.6.10a
-
Добрый день!
Вроде исправил ошибку, по ссылке https://yadi.sk/d/J9FKfUhrcndSOw (https://yadi.sk/d/J9FKfUhrcndSOw) можно скачать тестовую версию.
Если всё хорошо, подготовлю сборку для размещения на сайте.
Айрат
-
Всё заработало, спасибо!!! Пробовал с переключением QoS у тегов в 0 или 2.
-
При получении текстового значения, выводятся крякозабры. Как это можно починить?
-
Добрый день!
Дело скорее всего в кодировке. OPC сервер оперирует ANSI строками.
Видимо ваш клиент Unicode использует.
Какую программу используете для передачи сообщений?
Айрат
-
Добрый день! Спасибо! Данные передает контроллер наверняка в Unicode. Как то в arOPC кодировку поменять можно? Все клиенты, и под виндоус и андроид, которыми пользовался без проблем понимали текстовые значения...
-
Пока поменять нельзя.
Добавлю это дело в OPC сервер.
Сегодня, завтра.
Айрат
-
Добрый день.
Добавил для MQTT две кодировки, Unicode и UTF8.
Ссылка для скачивания: https://yadi.sk/d/GGqcVFNIdWfBpw (https://yadi.sk/d/GGqcVFNIdWfBpw)
Айрат
-
Спасибо! Всё отлично работает!!!
-
Доброго времени суток!
Есть ощущение что OPC сервер не корректно работает на отправку по QoS 2, скорее отправка происходит по QoS 0. Нет гарантированной доставки сообщения. Т.е. если плохая связь или контроллер в момент отправки сообщения от OPC сервера был занят, то сообщение не доставляется. Хотя при использовании других клиентов таких проблем нет.
-
Добрый день!
Надо посмотреть дошли ли данные от OPC сервера до брокера.
Дело в том, что за доставку отвечает отправитель, задача OPC сервера доставить данные до MQTT брокера, а дальше уже не его зона ответственности (https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ (https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/)).
MQTT брокер можно настроить (https://mosquitto.org/man/mosquitto-conf-5.html (https://mosquitto.org/man/mosquitto-conf-5.html)), что бы выдавал подробные логи.
Тогда будет точно видно где проблема.
Айрат
-
Спасибо!
Пробовал и с отправкой данные непосредственно с OPC сервера.
Я правильно понимаю, что именно клиент должен отправлять сообщение до тех пор, пака не получит подтверждения в получении пакета. А так как OPC сервер - это посредник между клиентом и MQTT сервером, то он не получает сведений о дошел пакет информации или нет, соответственно отправляет только один раз. Так как в своем проекте я пользуюсь СКАДой, это не клиент MQTT. Значит организация работы у меня будет по QoS 0 что бы я не выбрал.
Правильный вывод?
-
Похоже я не до конца понимаю как у вас там всё работает.
Набросайте схему пожалуйста, кто к кому и как подключен.
Айрат
-
На сервере установлено:
1. MQTT брокер Mosquitto-1.6.10a
2. arOPC сервер
3. Simple-Scada
Контроллер по MQTT через вифи общается с MQTT брокером
Simple-Scada через arOPC сервер получает данные от MQTT брокером
-
Спасибо!
Пробовал и с отправкой данные непосредственно с OPC сервера.
Я правильно понимаю, что именно клиент должен отправлять сообщение до тех пор, пака не получит подтверждения в получении пакета. А так как OPC сервер - это посредник между клиентом и MQTT сервером, то он не получает сведений о дошел пакет информации или нет, соответственно отправляет только один раз. Так как в своем проекте я пользуюсь СКАДой, это не клиент MQTT. Значит организация работы у меня будет по QoS 0 что бы я не выбрал.
Правильный вывод?
Не совсем.
Если вы с обеих сторон выберите QOS2, то вся система по нему и будет работать.
В MQTT отправитель отвечает за доставку пакета, не важно кто это, MQTT клиент или брокер. Кто отправил тот и в ответе.
MQTT клиенты, которые подключились к MQTT брокеру с QOS2, знают только о том дошёл их пакет до брокера или нет. А вот
информации от том дошёл ли этот пакет, до подписавшегося на топик клиента, они не имеют.
Если смотреть на вашу схему, то получается что пакеты от OPC сервера в любом случае попадают в MQTT брокер, т.к. весь обмен происходит внутри одной машины. И ещё, OPC сервер не отправляет повторяющиеся данные. Т.е. если вы, к примеру, со скады всё время будете писать в тег 1, пройдёт только первая запись, а потом ничего происходить не будет, т.к. значение тега не меняется.
Айрат
-
Есть проблема с последним релизом arOPC.
Надо передать данные из SCADA по ОРС к MQTT брокеру и прочитать с него же. Добавил устройство "симуляция", добавил брокера в настройках. Поставил галочку публикация описания в настройках брокера, период 2000 мс (2 секунды). Попробовал на двух различных ПК с различными ОС - поведение одинаково.
Проблемы:
1. Запустил arOPC - невозможно остановить. При нажатии "стоп" - пункты меню в окошке arOPC не доступны. Затем программа завершается с ошибкой. [Разобрался] проблема снята. В настройках программы должна стоять галочка "разрешить включение\выключение опроса устройств", что не очевидно.
2. При добавлении папки в устройство - она не показывается в дереве, но существует. Добавить снова с таким же имеем не дает, пишет что папка уже существует.
3. В arOPC создал два тега типа BOOL, один на подписку в топик1, другой на публикацию в топик 2.
На подписку: после старта сервера тег выделен желтым, и пока в топик1 не прилетит изменение хотя бы одного клиента - тег в сервер остается с желтой метко и без значения. Очевидно что это относится к Retain, но вопрос в другом. Тег в arOPC на подписке топик1 - принимает первое прилетевшее в топик1 значение, и в дальнейшем - не меняется, хотя в топик1 продолжают прилетать другие, изменяющиеся значения.
На публикацию: тег в arOPC меняет значение, в логах брокера видно что увеличивается количество сообщений и метки о получении брокером есть - но в поле значение не 0 или 1, а пустое место.
-
Добрый день.
В ближайшее время всё проверю.
Айрат
-
скриншоты по вопросу 2. Не зависит от того, запускается arOPC от имени администратора или пользователя.
.
(https://imageup.ru/img22/3750408/bufer-obmena01.jpg)
.
(https://imageup.ru/img184/3750411/bufer-obmena02.jpg)
.
(https://imageup.ru/img258/3750414/bufer-obmena03.jpg)
.
Часть текущего cfg файла - поле родитель разве должно быть пустое ? наверное "Device1" там должно быть. Развернуть каталог с Device1 в дереве не удается.
.
(https://imageup.ru/img114/3750431/cfg1.jpg)
-
Добрый день.
Спасибо за уточнения.
По вопросу возникновения ошибки с MQTT у меня получилось воспроизвести ситуацию, занимаюсь исправлением.
Айрат
-
Добрый день.
1. Есть ошибка в программе, если во время работы выбрать устройство типа "Симуляция" то возникает сообщение. В ближайшее время на сайте будет размещена новая версия OPC сервера.
2. Группа создаётся, но узел устройства не разворачивается, поэтому группу вы не видите (приложил изображение), на ваших скриншотах как раз такой случай. Подумаю, может надо разворачивать автоматически дерево конфигурации в которое был добавлен новый узел.
3. Здесь необходимо более подробное описание. Приложите, пожалуйста, конфигурацию OPC сервера, укажите каким клиентом пользуетесь для отправки сообщений MQTT брокеру, в каком виде этот клиент передаёт данные.
Айрат
-
по пункту 2. - не удается развернуть, как не нажимай, в этом и проблема. Попробовал сделать новую конфигурацию, все равно - если добавлять группу в устройство, она не разворачивается, и при этом даже добавленное устройство в конфигурации не видно. Если добавлять группу для теста в корень - то группа добавляется, и устройство сразу становится видимым. Но группы в устройстве не видны, дерево ниже устройства не разворачивается.
по пункту 3 - брокер mqtt.by, для тестов. Клиент для наблюдения - MQTT explorer
шаг 1
(https://imageup.ru/img20/3757956/s1.jpg)
шаг 2
(https://imageup.ru/img188/3757957/s2.jpg)
шаг 3
(https://imageup.ru/img104/3757958/s3.jpg)
шаг 4
(https://imageup.ru/img163/3757959/s4.jpg)
-
Еще одна проблема, туда же пункт 4.
При больших разрешениях экрана, более 1920 и установке масштабирования, как рекомендует ОС Windows 10 более 150% - кнопки "Ок" и "Отмена" в диалоге добавления устройства - уезжают за пределы формы диалога. То есть сама форма находится в пределах экрана - а кнопки и рамка за формой, нажать их нельзя.
-
Добрый день.
В контекстное меню, добавлю пункт "Развернуть."
Погоняю программу с большим разрешением и с соответствующим масштабированием, постараюсь поправить.
Айрат.
-
еще одна проблема - видимо некорректно работает опция "количество знаков после запятой". Не отбрасывает остальные знаки - 6 знаков так и остается. Версия ОРС последняя.
При этом в самом брокере к в топике строка - "25.7", все верно
(https://i.ibb.co/8nCLQfr/01.jpg)
.
(https://i.ibb.co/t2WBGVv/02.jpg)
-
Добрый день.
Я знаю об этом, это небольшое искажение возникает именно при преобразовании числа в строку в интерфейсе OPC сервера. С самими данными всё в порядке.
Айрат
-
а исправить это можно/планируется ?
-
Возможно чуть позже.
Задача ОРС сервера передать данные без искажений конечным получателям (ОРС клиент и MQTT), с этим всё в порядке. Интерфейс служит только для первичной диагностики.
Айрат.
-
Здравствуйте!
Возникла задача управлять имеющимися устройствами с MQTT именно через SCADA. Гугл предложил Ваш сервер. Есть несколько вопросов:
1) Я правильно понимаю процесс: для создания шлюза MQTT-OPC-SCADA нужно в arOPC создавать устройства, прописывать теги, привязывать их к топикам MQTT, затем уже в SCADA еще раз создавать такие же устройства и привязывать их к тегам теперь уже вашего OPC сервера? Туповатое уточнение, но тем не менее: то есть нет режима "транслировать все" и разбираться уже на стороне SCADA.(процесс создания шлюза не описан в инструкции)
2) arOPC не умеет разматывать строки JSON в топиках? Или умеет? Где посмотреть? (в инструкции нет об этом вообще ничего)
-
Здравствуйте!
1. Вы создаёте конфигурацию в OPC сервере, а SCADA просто получает список всех параметров из OPC сервера. В SCADA системе потом уже делаете привязку, OPC тегов из OPC сервера, к внутренним переменным. Может какие то другие решения есть, но я с такими не сталкивался.
2. До этого руки не дошли ещё. Что представляет собой JSON строка? В вашем случае.
Айрат
-
1) Понял, буду экспериментировать.
Просто как идею на будущее (после осознания как работает SCADA уточню идею): было бы здорово подписываться на общий топик устройства(подраздела устройства) и силами arOPC сервера вытаскивать из MQTT топика, теги (состояния и уставки) парсингом JSON строки.
Так же, по моему опыту, для тега лучше обеспечивать подписку на два топика: отдельно топик для установки параметра, отдельно на получение статуса, иначе, когда подписываешься на топик, в который сам же публикуешь, возникает "кольцо"(легко решается созданием двух тегов один на подписку, один на публикацию, вопрос удобства, и, извините, денег - лицензия на количество тегов). Сейчас к тегу можно прикрепить только один топик.
2) JSON как JSON: {"парамтр1":хх,"параметр2":yy,"параметр3":zz.qq,"параметр3":"строка",...}
-
1. Парсинг, наверное, как универсальное решение сделать не получится. А ради одного случая, смысла нет.
В arOPC проблема кольцевания решена, можете смело работать с одним топиком. Ну, а так да, идея разделения топиков, для тега, хорошая, добавлю в Task list.
2. Понятно. Тут возникает ограничение, такой топик будет доступен только на чтение. По идее это и было причиной, из за которой не стал добавлять разбор.
Айрат
-
В общем: без JSON грустно: политика "один топик-одно значение" сильно отъедает и без того мелкой оперативной памяти устройств (бестолковые, незначащие названия топиков надо хранить, перебирать и обрабатывать, при хранении в EEPROM получаем тормоза при считывании) и после десятка значений-топиков сильно неудобно ковыряться с этими слешами, вложениями и пр., т.е для средних(от 10 значений) и крупных проектов мертворожденная идея.
Постепенно разбираюсь и для меня удивительно, почему почти ни у кого MQTT не внедрен в SCADA, понятно, что промыслам принципиально неинтересен этот потребительский "ширпотреб", но этож все-таки какой-никакой, а тоже рынок сбыта, так как главной проблемой большинства проектов является именно интерфейс пользователь-система.
Уговариваю:
Так это ж пока "один случай"(хотя, судя по ветке форума, уже два), вряд ли MQTT канет в лету в обозримом будущем(цена интерфейса к MQTT 1usd в розницу(ESP8266+esplink), цена modbus tcp -? ), а инструмента, позволяющего за адекватные деньги подключить "промышленный" интерфейс scada к ширпотребовской электронике и поделкам пионеров кроме Вашего пока нет. Ознакомьтесь с обсуждением какого-нибудь zeegbeetomqtt сообщества.
2)О JSON: такие топики со значениями только считываются такой длинной строкой с разнотиповыми значениями, запись можно делать и по одному значению, в виде {"newstate":1}, в устройствах уже реализован обработчик JSON и ему безразлично со сколькими парами ключ-значение работать.
Прошу прощения за оффтоп.
-
1. Не совсем пойму выгоду от использования JSON. Ну завели вы один топик, в который сбрасываете JSON пакеты. Логика от этого не поменялась. Вы всё равно оперируете парами {"параметр": значение}, а это значит всё равно где то надо хранить название параметра, для того, что бы определить, какие данные поступили в JSON пакете. Плюс нужен парсер JSON пакетов. Каким образом это обходится при использовании JSON?
2. Да, действительно, можно оперировать отдельными парами. В этом случае, конечно, придётся отбросить QOS и Retain функционал, либо он будет неполноценным. Но если это не критично, то почему бы и нет. Вы правы, надо будет это дело реализовать.
Я понимаю, работать со строкой и JSON пакетом удобно, наглядно, много готового ПО, опирающегося на это. Но почему то никто не вспоминает, что сам по себе MQTT протокол способен передавать данные в любом виде. Что бы передать к примеру число 4 294 967 295 не надо передавать 10 байт, в виде строки, достаточно 4 байт. А контроллеру потом не надо будет парсить JSON и преобразовывать строку в число. Да и в оперативе, не надо хранить название параметра, можно HASH сумму посчитать и по ней искать, всё одно будет быстрее чем разбор JSON пакета и приведение параметров к нужному типу.
Но, это уже не каждому пионеру под силу).
Айрат
-
1. не совсем так. Пытался сочинить пример с калькуляцией, короче чем на два экрана не выходит (стало любопытно, потом сделаю тестовый пример).
Тезисно: пример из проекта
Есть помимо прочего 5 вентиляторов (автоматизация сушильного шкафа сейчас работает в iot-MQTT panel в планшет, есть еще разная автоматика, принято решение привести к общему знаменателю, ввести SCADA )
Для каждого вентилятора:
публикуем: состояние, режим работы, интервал включения, длительность включения, номер используемого датчика температуры, сигнал аварии (всего 7)
подписываемся: новое состояние, новый режим работы, новый интервал включения, новая длительность включения, новый номер используемого датчика температуры (всего 6)
все значения параметров byte (меньше не бывает (битовая упаковка неоправдана))
при подходе "по топикам" длина топика постоянно нарастает, обработчики циклически работают с динамическими массивами (string) меняющейся длины, созданными не тобой (при 2 кб sram те еще грабли, память фрагментируется (массивы ведь должны хранится непрерывно) и программу часто срывает ).
при JSON мы один раз ищем есть ли "FANx" в названии топика, если да, то один раз парсим JSON раскидывая параметры в регистры.
Плюс данные из "приемника MQTT" спускаются по SLIP протоколу, а там число-это число, строка - это массив символов.
Магия с HASH (кстати, где посмотреть об этом способе, а то я слова по отдельности понимаю, а в смысл вместе они не складываются ))) )оправдана когда ты сам полностью в одном устройстве поднимаешь TCP-IP-MQTT стек , на имеющимся PHY (wi-fi, ethernet) и на нем же "шевелишь ногами"- тут как всегда, это или очень дорого или очень сложно (читай объемно) или очень медленно. Выгоднее использовать отдельный контроллер, который будет заниматься только стеком TCP-IP-MQTT, а с основным будет общаться по SLIP.