Коммуникатор — новые возможности ?

Стартовая страница Форумы Новые идеи Коммуникатор — новые возможности ?

Просмотр 15 сообщений - с 1 по 15 (из 21 всего)
  • Автор
    Сообщения
  • #16128
    manjey73
    Участник

    Добрый день, Михаил. Ковыряясь с драйверами появились новые идеи для Коммуникатора.

    1. Сделать один файл для Коммуникатора, который будет хранить переменные, сохраняемые при перезапусках Коммуникатора или линии связи и доступные из драйвера при добавлении линии и ее остановке.
    На словах. Что-то вроде CommonProps но глобально.

    Состояние линии

    В состоянии линии можно в строку запихнуть хоть все переменные, но:
    это будет не очень красиво. Можно ли их будет вытащить при добавлении линии из драйвера при перезапусках ? Не очень помню, можно ли из драйвера узнать Номер линии связи ?

    • Эта тема была изменена 1 год, 6 месяцев назад от manjey73.
    #16130
    manjey73
    Участник

    Идея состоят в том, что Коммуникатор будет хранить в одном файле данные тех линий связи, в которых при OnCommLineTerminate и(или) OnCommLineAbort было активировано сохранить набор переменных (сделать возможность отмечать что именно сохранять).
    А при OnAddedToCommLine соответственно выполнять проверку — «есть что для меня?», если есть, то Коммуникатор вычитывает данные и отдает драйверу. Далее тот может работать через CommonProps с переменными. Тем более там их можно скрывать и не показывать. Всякие булевые, int, DateTime и так далее.

    з.ы. мне понравилось через CommonProps, очень удобная штука оказалась, но заполнять ее приходится каждый раз по новой при добавлении линии, а некоторые переменные все же требуют сохранения при перезапусках, создавать для этого отдельные файлы по номерам КП не всегда практично. Можно конечно формировать один файл на драйвер. Но если такой механизм будет в Коммуникаторе, будет гораздо лучше.

    2. Нужно чтобы Коммуникатор, посредством Сервера мог сообщить драйверу время сохранения БД Scada, а в будущем, время сохранения каждого канала, когда появится такая возможность.

    • Этот ответ был изменен 1 год, 6 месяцев назад от manjey73.
    #16132
    Romiros
    Участник

    В 5.8 добавлялись директории storage для сервера и коммуникатора, если не ошибаюсь для этих целей. В истории версий можно глянуть.
    А какие параметры линии связи у Вас динамически меняются, что нужно загружать их последнее значение?

    #16133
    Romiros
    Участник

    Данные сохранения канала в БД относится к конкретному КП, и хранить это в линии связи неправильно.

    #16134
    manjey73
    Участник

    Я не про то, чтобы хранить время сохранения в БД в линии связи, я про то, чтобы драйвер мог получить эти данные через Коммуникатор от Сервера по запросу например.

    На счет сохранения переменных, нужно между различными КП, если они относятся к одному устройству, некоторые переменные хотелось бы сохранять когда происходит перезапуск Коммуникатора или Линии. з.ы. Сейчас CommonProps использую, но если мудрить с чтением из файла, надо знать на какой линии связи находится КП ??? и возможно ли вообще использовать CommonProps как хранение не уверен?

    Не, можно извратиться сделать для драйвера файл специальный, куда будет заноситься номер КП и переменные. Но если подобный механизм будет реализован в самом Коммуникаторе будет лучше. А будет он использоваться или нет. вопрос уже 10-й.
    Вариант аналогичный CommonProps и один файл на все линии. Если используем, там будет запись, если нет, не будет…

    #16135
    Romiros
    Участник

    я про то, чтобы драйвер мог получить эти данные через Коммуникатор от Сервера по запросу например

    Это уже есть, у линии связи есть ServerComm.

    На счет сохранения переменных, нужно между различными КП, если они относятся к одному устройству

    Если два КП опрашивают один и тот же прибор? Можете привести пример?

    Уже ранее обсуждали, что неплохо бы добавить KpCustomProps (или CommonProps не помню, короче пользовательские параметры) по аналогии с линией связи. В них было бы удобно хранить настройки подключения к прибору, чтобы не создавать отдельный конфигурационный файл для каждого КП. Тем более бывает что нужно каких-то четыре параметра и больше времени уходит на создание конфигурационной формы и организации чтения записи xml файла. Эта функция была бы очень полезна.

    Хранить сведения о последних отправленных данных на сервер лучше все-таки на самом сервере. Это более надежно. Перед стартом опроса считали последние сохраненные в БД данные и продолжаем с этого момента. Хранение файла в коммуникаторе — это целый геморой. Для гарантированного сохранения, таких файлов по хорошему должно быть два, чтобы не нарушить целостность файла, если в момент записи в него происходит допустим отключение питания компьютера. Я пробовал по разному и в файлах и в БД. Остановился на БД. Так элементарно спокойнее. Тем более когда система админится из различных администраторов, или могут измениться номера линий или КП или ещё что, с БД реально спокойнее.

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

    • Этот ответ был изменен 1 год, 6 месяцев назад от Romiros.
    #16137
    manjey73
    Участник

    Два КП, например счетчик, один КП опрашивает постоянно мгновенные значения, второй КП опрашивает Энергию, настроечные параметры и т.д. в несколько раз реже. С появлением раздельного времени хранения данных, для второго КП можно каналы сохранять только раз в час и по изменениию (если поменяли какие-то настройки) с отметкой времени и каким оператором. з.ы. я же сейчас делю иногда шаблоны на две части для этого и создаю два КП для одного прибора. То есть у меня вот счетчик Меркурий 236, для КП, которые читают мгновенные значения один шаблон, для КП, которые читают энергию, второй шаблон.

    CommonProps позволяет хранить переменные и обмениваться в драйвере ими между КП уже сейчас, не хватает только возможности сохранять выбранные из списка переменные, включенные в CommonProps при перезапусках линии связи или Коммуникатора.

    з.ы. постараюсь сегодня выложить обновление для счетчика Меркурий 23х. Там это реализовано. Есть даже в тех исходниках, что буквально недавно выкладывал. Просто тут прикрутил еще автоматическую синхронизацию часов счетчика, команды, чтение профиля средних мощностей и хз чего еще 🙂 Первоначально стояла задача перейти на шаблон и сделать посылку широковещательной команды фиксации данных на линию.
    А чтобы каждый вызов драйвера двух КП, но одного прибора не повторял те же процедуры чтения (открытие канала связи, авторизация, чтение времени и т.д.), как раз и задействовал CommonProps. Это сокращает время опроса как минимум. Для приборов, у которых нет понятия глобальных групповых опросов, где каждый чих это команда — ответ вполне актуально.

    #16138
    manjey73
    Участник

    И кстати CustomProps тоже можно использовать уже сейчас, создавая переменные в виде
    ID_parametr, то есть для двух КП но одного прибора можно сделать

    Addr20_UserPass
    Addr20_AdminPass

    а можно
    NumKp_date

    там тоже есть вариации поиграться. Но и там и там есть недостаток.
    Часть переменных лучше не светить и не иметь возможность редактировать например. CommonProps тут прямо таки подходит. А CustomProps подходит когда надо иметь возможность их редактировать, тот же пароль сменить например. Но там светится полностью все и есть редактирование.

    • Этот ответ был изменен 1 год, 6 месяцев назад от manjey73.
    #16141
    Romiros
    Участник

    Два КП, например счетчик, один КП опрашивает постоянно мгновенные значения, второй КП опрашивает Энергию, настроечные параметры и т.д. в несколько раз реже.

    У меня это разруливается логикой драйвера.

    Addr20_UserPass
    Addr20_AdminPass

    Не вариант. Для каждого КП должны быть свои, иначе слишком сложно для пользователей.

    #16142
    manjey73
    Участник

    Так можно и для КП свои настройки меть в CustomProps, в качестве идентификатора выступает тогда номер КП.

    Разруливать на уровне драйвера не всегда удобно. Ну можно конечно в шаблоне указать время опроса или период опроса тех или иных каналов еще и в драйвере, вопрос только зачем если это можно делать в свойствах Опрос КП в Коммуникаторе ?
    Хотя тоже конечно один из подходов

    Было бы супер, когда появится раздельное время хранения данных в БД Scada как это это использовать в драйверах… Типа канал пишется не чаще раза в минуту, драйвер это знает и читает данный параметр только раз в минуту, возможно с небольшим офсетом или после чтения (если после минуты оно произошло, много устройств на линии и т.д) запись попадает в нужную минуту. Но это уже может и слишком.

    #16157
    Mikhail
    Модератор

    Добрый день!

    Можно ли их будет вытащить при добавлении линии из драйвера при перезапусках ? Не очень помню, можно ли из драйвера узнать Номер линии связи ?

    Номер линии из драйвера сейчас нельзя получить. Если только её явно записать в пользовательские параметры линии. Согласен, что доступ к номеру линии будет полезен.

    На текущей версии при желании можно самому реализовать сохранение и загрузку переменных при остановке и запуске Коммуникатора. Для хранения произвольных данных предназначена папка Storage. Путь к этой папке есть в AppDirs

    За идеи спасибо.

    #16167
    manjey73
    Участник

    обновил драйвер Меркурий 23х на ГИТ, вот там поизголялся и с CustomProps и с CommonProps. Единственное чтобы не городить что-то самостоятельно, некоторые переменные, используемые в CommonProps хотелось бы иметь сохраняемыми на уровне Коммуникатора. Например из-за того, что команду синхронизации времени в счетчик можно послать только один раз за сутки, пришлось повозиться. так как при перезапусках все время пытался синхронизировать время и ругался. Была бы переменная с автосохранением, получилось бы проще в реализации. Ну и в принципе было бы неплохо иметь различный набор возможностей.

    #16184
    manjey73
    Участник

    Вот что еще вспомнил. Попробую объяснить на примере драйвера Modbus.
    Когда мы в Администраторе выбираем Коммуникатор — Драйверы — KpModbus и вызываем свойства, мы можем создать новый шаблон. Или аналогично, когда мы добавили Линию, добавили в Опрос КП драйвер Modbus и нажали свойства, без указания шаблона так же вызывается окно создания шаблона.

    Так вот, при добавлении в Опрос КП линии опроса и нажатия свойства, нужна возможность из этой части кода иметь доступ к порту, который настроен на эту линию. Что-то аналогичное Session с проверкой занятости порта, если линия настроена как COM порт.
    Нужно для организации сканирования устройств. То есть мы выставили в окне Опроса Адрес прибора, либо оставили 0 (тогда скан будет происходить с перебором адресов), убрали привязки к Серверу. Вызвали свойства, указали какие-то базовые настройки и запустили скан. Если что-то нашлось, отмечаем требуемые переменные и сохраняем шаблон. Полезно для различных протоколов — M-Bus, Ethernet/IP, вероятно BacNet и наверняка и других подобных.
    Можно конечно писать отдельные утилиты для этого, но если это будет функционалом именно Scada будет гораздо лучше…

    #16193
    Mikhail
    Модератор

    Идея понятна, как реализовать надо будет подумать.

    #16197
    manjey73
    Участник

    Ну, если вкратце, можно использовать те же методы, что и в самом драйвере.
    Session, SendCmd, OnAddedToCommLine, OnCommLineStart и так далее.
    Ведь по сути, когда мы запускаем линию, наш код выполняется во всех этих методах и мы можем этим манипулировать. Например я выполнял опрос и сохранял параметры в шаблон в файл xml по параметру init в шаблоне при первом запуске, потом сбрасывал init и выводил сообщение о перезапуске линии.

    Драйвер при этом работает без привязок к Серверу. Пусть это будет скажем KpXXXPreLogic (или как-то иначе), так же унаследованный от Logic. Но когда мы запускаем окно, иметь возможность из него нажатиями кнопок останавливать и запускать опрос основной части кода и стартовать уже опрос текущей части. Например основная часть KpXXXLogic привязана к серверу, а текущая работает без привязок…

    Чтобы из этого кода можно было запускать и останавливать линию хотя бы на локальном ПК, где и Администратор и Сервер и Коммуникатор вместе. В идеале конечно возможность управлять даже на удаленном. но для начала хотя бы на одном. Уже будет что-то… По крайней мере можно подключиться к линии с ПК разработки, выполнить все настройки и потом уже готовые настройки перенести на действующий ПК.

Просмотр 15 сообщений - с 1 по 15 (из 21 всего)
  • Вы должны авторизироваться для ответа в этой теме.