Не знаю. У нас таких нет.Сообщение от IVM
Точнее будет сказать, не только в Чебоксарах
Не знаю. У нас таких нет.
Точнее будет сказать, не только в Чебоксарах
VladimirIS значек GIT ведет на IntraHouse, вы тут пишите что это другой продукт, не нашел там ничего по IntraScada.
Ну ладно, другие вопросы.
1. В ядре реализовано использование каналов связи, которые передаются плагину? COM порт и его настройки, TCP, UDP, Com over TCP(UDP) ?
2. Если реализовано, как происходит сессия опроса? необходимо все реализовывать внутри плагина?
3. Независимо где реализация, вариант остановки по последовательности байт, байту, символу, есть реализация? Например дополнительным модулем? видел там какой-то com port tools
В общем нужна хорошая "рыба" для плагина с подробным описанием и желательно рабочим примером для более слабых программистов...
з.ы. на чем удобнее программировать именно JS, чтобы подсвечивал синтаксис, давал подсказки, возможность отладки под Windows чтобы не плодить сущностей ?
melky
Ядро системы ничего не знает про то, как работать с каналами связи.
Работа с каналами связи - это задача плагинов.
Про остановку вообще не понял. Остановка плагина?
Для начала можете посмотреть про общую концепцию плагинов https://docs.intrascada.com/ru/plugin_concept
VladimirIS то есть настройки COM портов, TCP(UDP) соединений полностью возложены на пользователя и требуется программировать в плагине?
На счет остановки неправильно поняли. Есть протоколы, где неизвестна длина пакета от устройства и является плавающей величиной. То есть нельзя задать буфер определенного размера для входящих пакетов. Или если мы задаем заведомо больший буфер, то тупо ждем выставленный таймаут.
Тут есть два варианта решения, останавливать опрос по определенному набору байт, характерному для того или иного устройства (протокола) или останавливать опрос на заголовке пакета, где указана длина и задавать дополнительный буфер для остальной части пакета.
Вот в плагине Modbus вы как решили данную задачу? изначально рассчитываете длину ответа или смотрите на длину в заголовке?
p.s. хотя вы может и понятия не имеете как реализовано в Modbus, так как используете какую-то готовую библиотеку NodeJS если я правильно понял. А с самодурными протоколами акромя него небось и не сталкивались...
Например ISO61170 (МЭК61170) счетчики Энергомера, расходомеры газа ЕК и фиг знает что еще. Символьный протокол, параметр может быть передан как 8,00 или как 12,00 например мощность в кВт - длина пакета будет отличаться
Может для плагинов есть модуль NodeJS который бы занимался всей этой рутиной и просто его подключать в коде плагинов????
Еще мне пока не очень ясно с настройками каналов в интерфейсе системы.
Могу ли я все переменные завести сразу в систему? Быстро отключить те, которые я не захочу использовать?
Опять же, протоколы есть разные, устройства тоже. Например MBus присылает полностью все переменные в телеграмме, но из них мне необходима только часть в системе. Телеграмма это ответ на один запрос.
Другие протоколы подразумевают несколько запросов на разные наборы параметров, при этом часть переменных мне нужна из запроса, а часть нет. Когда не нужны все из группы, я должен полностью выключить запрос этой группы. Когда мне нужна только часть, запрос должен остаться, но связь с тегами Scada должна быть только у части переменных.
Возможность использовать шаблоны настроенного устройства, режим инициализации при первом запуске, изменение шаблона на лету. Например xml или это чудо json, не так важно...
Последний раз редактировалось melky; 10.01.2022 в 12:03.
Такой стиль общения заставляет меня прекратить дискуссию
VladimirIS и что в моем стиле? вам рассказать прелести некоторых протоколов от производителей, где идет разрыв переменной на две страницы памяти или использования в одном ответе чисел как в HEX формате так и в BCD формате или расчет контрольной суммы то однобайтовой, то двухбайтовой, причем с разным набором данных в зависимости от типа КС?
Хотите развития системы, надо помогать и главное хотеть этого. В том числе и прислушиваясь к пользователям, как существующим так и потенциальным.
Лично мне интересна система своей кроссплатформенностью но как и что в ней придется писать явно, а что уже реализовано пока не понимаю.
Вроде лично к вам пока не было претензий, или расскажите как с вами надо общаться?
Возникли вопросы по ходу.
Каким образом происходит групповое чтение параметров Modbus ?
Каким образом драйвер чередует опросы двух и более устройств на линии ?
Исходя из того, что каналы связи надо программировать внутри плагина, как его писать с учетом того, что устройств на линии будет два и более?
Группировка при чтении позволяет существенно снизить число обращений к устройству modbus.
Универсальный плагин modbus предлагает два варианта группировки:
Вариант 1. У канала (адреса modbus) ставится галка: "Группировать при чтении".
В этом случае плагин сам группирует последовательно идущие адреса внутри каждого UnitId (возможно, с небольшими разрывами) с учетом параметра "Max кол-во слов при чтении диапазона" (250 для стандартного протокола, можно уменьшить)
Вариант 2. Ручная группировка. В этом случае в канале указывается "Название группы" (по сути идентификатор), по которым плагин соберет группы для опроса
Речь идет, видимо, об устройствах с разным UnitId, подключенным к одному порту.
Если порты разные, система позволяет запустить отдельный экземпляр плагина для каждого порта. Тогда опрос идет практически параллельно, так как каждый экземпляр работает в отдельном процессе.
Если порт один - чуда нет, последовательно выполняются все операции чтения для каждого UnitId по порядку возрастания.
Операции записи для любого UnitId выполняются сразу при поступлении. Далее опрос продолжается.
Конечно, возможны задержки, если какое-то устройство перестает отвечать. Нужно установить адекватное "Ожидание ответа на запрос (ms)".
Не совсем понятно, что имеется в виду. "каналы связи надо программировать внутри плагина" - нет, не надо.
Для экземпляра плагина задается COM порт для Modbus RTU или IP+порт для Modbus TCP/ RTU over TCP
Универсальный плагин может работать с любым количеством устройств с разными UnitId
Каналы настраиваются и передаются плагину при запуске.
Есть механизм простого создания каналов для идентичных устройств c разными UnitId
- создаем узел (папку) с unitid = 1 (например). Внутри создаем каналы. Затем просто копируем папку и меняем unitid в узле.
Если же modbus очень нестандартный (по сути и не модбас), придется написать свой плагин. Можно, на базе существующего.
Ну вот если я на счетчик буду пытаться делать плагин. Счетчиков 2 или больше. В плагине задается COM порт и его настройки? Или в какой-то надстройке которая и будет разруливать последовательные запросы? Каждый счетчик имеет несколько запросов и ответов ну по аналогии с Modbus группами.Не совсем понятно, что имеется в виду. "каналы связи надо программировать внутри плагина" - нет, не надо.
Еще такой вопрос, два(или более) устройства в плагине могут иметь общие переменные в рамках одной линии связи? (одного COM порта)
тут пояснение требуется. Например плагин прибора один, по аналогии с Modbus на линии 2 устройства, это один экземпляр плагина будет запущен под разные id устройства ? в данном случае внутри плагина можно организовать глобальные переменные только для данного экземпляра плагина, чтобы эти переменные были доступны только тем устройствам, которые находятся на данной линии связи?
Как или точнее кто в Modbus считает CRC? можно как-то подключить модуль (и что конкретно подключить) чтобы не повторять тот же самый код в плагине?
з.ы. вообще идея отдельной dll (ну или модуля в рамках NodeJS) как бы тоже напрашивается, так как многие устройства используют похожие расчеты CRC например Modbus, Меркурий, тот же Пульсар и так далее и писать каждый раз в каждом плагине это ну как бы глупо.
Ну и есть куча других функций по аналогии, например преобразования из BCD в DEC и обратно, из строки в HEX и обратно и так далее.
Есть подобный функционал у вас? можно ли использовать в плагинах функции ядра системы и если можно то как?
Проще говоря, есть ли доступ к функциям ядра и список того, что можно использовать при программировании ?
Последний раз редактировалось melky; 12.01.2022 в 13:16.
Разработчик плагина сам решает, какие параметры ему нужны и как будут устроены каналы.
Для этого в файлах json специального формата описываются форма для параметров и форма для каналов: https://docs.intrascada.com/ru/pg143
Пример: небольшая часть формы параметров плагина Modbus
{"prop": "timeout","title": "Ожидание ответа на запрос","default": 5000, "type": "number"},
{"prop" : "sendChanges", "title": "Отправлять только изменения", "type": "cb"}
Вы можете посмотреть код плагина, который установлен, прямо в админке. Например для Modbus, в разделе Плагины->MODBUS на вкладке Редактор. Формы находятся в папке v5
Ядро использует эти формы для ввода и передает данные плагину, т е плагин получит те параметры, которые определил (timeout, polldelay, ...)
Аналогично, система никак не ограничивает, как будут устроены ваши каналы. Канал имеет id, r - флаг чтения, w - флаг записи. А остальное = требования протокола + ваша фантазия.
Никаких надстроек, опрос выполняет сам плагин. Сколько и какие нужны запросы - сам отправляет, получает, парсит, как хочет.
В принципе, если пишется специализированный плагин, набор каналов известен и не требуется настройка со стороны пользователя, плагин может сам объявить каналы, описав их в манифесте или отдавать их при старте. Или даже можно отдавать динамически
Пример 1. Плагин jethomed1: https://github.com/intrahouseio/ih-v5-jethomed1-plugin
Плагин отдает фиксированные каналы с заранее заданными ID при старте, а датчики 1-Wire отдает динамически при подключении
Пример 2. Плагин laurent https://github.com/intrahouseio/ih-v5-laurent-plugin
Все каналы прописаны в манифесте
Просто нужно решить - что у вас является значением канала, которое будет отдаваться в ядро.
Общие переменные-параметры или переменные сеанса? В любом случае ответ - да, это реализуется просто.
Такой функционал уже давно есть в любом языке высокого уровня. В javascript это элементарно, причем гуглится на раз:
- parseInt( dec.toString(10),16); // DEC => BCD
- parseInt( bcd.toString(16),10); // BCD => DEC
- parseInt( hexString, 16); // HEX => BCD: '20' => 32
- yourNumber.toString(16); // BCD => HEX: 32 => '20'
API плагина - https://docs.intrahouse.ru/ru/pg142
Минимальный плагин - https://docs.intrahouse.ru/ru/pg141
И другие разделы в пункте "Источники данных" -> "Разработка плагина"
Там есть, как работать с ядром, как создать свои формы для параметров плагина и для каналов.
Ваши права
Ответить с цитированием