- В этой теме 23 ответа, 3 участника, последнее обновление 9 лет, 4 месяца назад сделано
.
-
Записи
-
Было бы классное решение привязывать все настраиваемые параметры приборов вообще без привязки к БД, так как они не нужны…
Так не правильно. Каждый элемент скады должен заниматься своим делом. Отображение в web и управление это дело сервера, а не коммуникатора. В базе 65000 каналов, чего её жалеть?Не столько жалеть, сколько они вообще в базе не нужны.
Например 16-ти канальный регистратор импульсов.
16 значений понятно — в базу писаться должны
а 16 значений весов импульсов на кой в базе нужны ?
А корректировка времени прибора зачем в базе ?Варианта 2, отключать линию связи, подключаться родным ПО и сделать настройки, либо сделать их ДО установки приборов
1. затык №1 — не все ПО умеет работать поверх TCP или UDP через преобразователи интерфейсов
2. необходимо остановить опрос, сделать дополнительные манипуляцииОкно Web только для того, чтобы открыть и показать данные, ведь Редактор схем есть, который готовит схему в представлении, есть плагин, который эти схемы показывает, скрестить одно с другим и получится схема для настроек приборов.
У меня на счетчик сейчас 12 параметров настроек лимитов, минус 2 тарифа — итого 8 параметров, а счетчиков 100, 200 и т.д. 200*8=1600 сигналов, которые пишутся в БД каждую минуту ? это расточительно не столько в размере, как еще и во времени обработки данных сигналов.
Ну и придумать вместо Ракеты для настроек индикатор «Шестеренка» или «Гаечный ключ» 🙂
Правильно ли я понимаю: при записи данных в прошлое, если такой временной срез не существовал вообще, то он нормально создается. А вот если он существовал, то запишутся только те каналы, которые существовали?
Именно так.
Сформулируем общую задачу, собираем народ, сделаем коммерческое предложение, от которого невозможно отказаться ?.
Звучит заманчиво 🙂
Я уже предлагал Михаилу сделать голосовалку по тем или иным моментам, с определением конечной цены за модуль
Не встречали готовый движок, который бы подошёл?
эти механизмы в последующем должны быть в составе ядра и бесплатны.
Базовые механизмы должны быть бесплатны, согласен.
Еще предлагал как-то реализовать механизм настраиваемого WEB окна через команды управления,
Помню. Для этого и была сделана настройка веб-приложения для выбора плагина отправки команд. По сравнению с архивами — это локальная задача.
Не знаю, насколько локальная, но было бы удобно использовать встроенный механизм многократно, не занимаясь разработкой WEB для каждого прибора в отдельности.
Сущности то ведь похожи.
1. Есть переменные, которые надо писать в минутные, часовые базы — мониторинг
2. есть переменные, которые необходимо считывать раз в день, месяц (в определенные дни, часы для снижения нагрузки на запросы, либо задавать период и чтобы они по очереди опросились за данный период) — архивные данные
3. Есть переменные для настроек прибора, включение/выключение режимов, синхронизация времени, какие-то параметры — им вообще в базах делать нечего, но можно прилепить к архивным, чтобы в последствии наложить на них чтение действий операторов.
- Для ответа в этой теме необходимо авторизоваться.