Ответы в темах
-
Сообщения
-
Если проблема в дублировании, то нужно проверить, какие у Вас версии Сервера и Коммуникатора.
Версия коммуникатора: 5.1.1.0
Версия Сервера: 5.1.1.0Данные отправляются в БД после того, как получены Сервером от Коммуникатора. Коммуникатор отправляет данные на Сервер после опроса прибора.
По опросу или по периоду передачи данных на сервер. По периоду передает все данные. Если период = 0, то только те, которые изменились.
Кстати, в следующей версии Коммуникатора появится опция, чтобы после опроса КП отправлять на Сервер все теги КП, а не только изменившиеся.
Т.е. при периоде = 0 буду приходить все данные? Это, как мне кажется, решит мою проблемму.
Я просто не понимаю, почему необходимо как-то распарсивать таблицу, приведенную мной выше таким образом, чтобы корректно селектить нужное значение из 2х строк, которые для меня являются одним и тем-же значением с разницей в 30 мс?
Можно-ли заставить отправлять Коммуникатор данные на Сервер по какому-то триггеру?
Напомните, пожалуйста, как именно Вам нужно, чтобы передавались данные в БД?
В идеале хотелось бы пачками с канала 1 по канал n с одним таймштампом. Потом еще одна пачка и т.д.
Моя идея была в том, чтобы триггер срабатывал на значение 0, вычитывал до времени триггера со значением 1 и записывал в таблицу. На триггер со значением 1 не имеет смысл срабатывать, т.к. так одиночные инсерты из модуля дб и следующих данных еще нет.
Ну или подскажите примерный алгоритм триггеров чтобы корректно распарсивать такие данные. Я не смог с ходу придумать.По поводу дублирования — поищите здесь на форуме уже разбирались похожие вопросы.
Нет, как оказалось, не понял.
При установке в коммуникаторе периода передачи на сервер равного 0 приходят только те данные, которые изменились — что для нас не подходит, т.к. некоторые данные и не предполагалось изменять, но они нужны для обработки.
При установки 1 секунды приходит следующее:2019-04-17 12:52:35.94572 | 61 | 0 | 1
2019-04-17 12:52:35.976992 | 61 | 0 | 1
2019-04-17 12:52:36.023894 | 141 | 11.1099996566772 | 1
2019-04-17 12:52:36.023894 | 142 | 12 | 1
2019-04-17 12:52:36.023894 | 143 | 13 | 1
2019-04-17 12:52:36.023894 | 144 | 14 | 1
2019-04-17 12:52:36.023894 | 145 | 15 | 1
2019-04-17 12:52:36.023894 | 146 | 16 | 1
2019-04-17 12:52:36.023894 | 147 | 17 | 1
2019-04-17 12:52:36.023894 | 148 | 18 | 1
2019-04-17 12:52:36.023894 | 149 | 19 | 1
2019-04-17 12:52:36.023894 | 150 | 0 | 1
2019-04-17 12:52:36.023894 | 151 | 1000 | 1
2019-04-17 12:52:36.023894 | 152 | 900 | 1
2019-04-17 12:52:36.023894 | 153 | 1 | 1
2019-04-17 12:52:36.023894 | 154 | 2 | 1
2019-04-17 12:52:36.023894 | 155 | 3 | 1
2019-04-17 12:52:36.023894 | 156 | 4 | 1
2019-04-17 12:52:36.023894 | 157 | 5 | 1
2019-04-17 12:52:36.023894 | 158 | 6 | 1
2019-04-17 12:52:36.023894 | 159 | 7 | 1
2019-04-17 12:52:36.023894 | 160 | 8 | 1
2019-04-17 12:52:36.023894 | 161 | 9 | 1
2019-04-17 12:52:36.023894 | 162 | 101 | 1
2019-04-17 12:52:36.023894 | 163 | 0 | 1
2019-04-17 12:52:36.055156 | 141 | 11.1099996566772 | 1
2019-04-17 12:52:36.055156 | 142 | 12 | 1
2019-04-17 12:52:36.055156 | 143 | 13 | 1
2019-04-17 12:52:36.055156 | 144 | 14 | 1
2019-04-17 12:52:36.055156 | 145 | 15 | 1
2019-04-17 12:52:36.055156 | 146 | 16 | 1
2019-04-17 12:52:36.055156 | 147 | 17 | 1
2019-04-17 12:52:36.055156 | 148 | 18 | 1
2019-04-17 12:52:36.055156 | 149 | 19 | 1
2019-04-17 12:52:36.055156 | 150 | 0 | 1
2019-04-17 12:52:36.055156 | 151 | 1000 | 1
2019-04-17 12:52:36.055156 | 152 | 900 | 1
2019-04-17 12:52:36.055156 | 153 | 1 | 1
2019-04-17 12:52:36.055156 | 154 | 2 | 1
2019-04-17 12:52:36.055156 | 155 | 3 | 1
2019-04-17 12:52:36.055156 | 156 | 4 | 1
2019-04-17 12:52:36.055156 | 157 | 5 | 1
2019-04-17 12:52:36.055156 | 158 | 6 | 1
2019-04-17 12:52:36.055156 | 159 | 7 | 1
2019-04-17 12:52:36.055156 | 160 | 8 | 1
2019-04-17 12:52:36.055156 | 161 | 9 | 1
2019-04-17 12:52:36.055156 | 162 | 101 | 1
2019-04-17 12:52:36.055156 | 163 | 0 | 1Всё, что я находил насчет дублей на форуме это касалось таймштампа и решалось игнором или апдейтом. Но я не нашел ошибок на стороне Postgres и данные то есть. Просто два раза с разницей в миллисекунды. Увеличение периода картины не меняет.
Буду признателен на ссылку, где это обсуждалось.Какая была причина?
Не в бобине=) Некорретный триггер в БД, как следствие не правильно отрабатывающая функция и неправильное поведение
Я пошел по предложенному Вами пути:
Есть 2 кп, один это триггер, второй это данные. Модуль автоуправления читает 2 кп при триггер = 1. Сервер получает данные и они отображаются в срезах. Вот только модуль экспорта в БД как-будто шалит. База данных пустая. Скрипты в модуле из мануала для Postgres. Стоит 11 Postgres. При перезагрузки коммуникатора записывается некая пачка данных, а потом опять тихо. Сможете подсказать, в какую сторону копать?Нашел в чем причина.
По поводу дублирования — поищите здесь на форуме уже разбирались похожие вопросы.
Понял в чем причина, спасибо.
Я пошел по предложенному Вами пути:
Есть 2 кп, один это триггер, второй это данные. Модуль автоуправления читает 2 кп при триггер = 1. Сервер получает данные и они отображаются в срезах. Вот только модуль экспорта в БД как-будто шалит. База данных пустая. Скрипты в модуле из мануала для Postgres. Стоит 11 Postgres. При перезагрузки коммуникатора записывается некая пачка данных, а потом опять тихо. Сможете подсказать, в какую сторону копать?Так же не совсем понятно, почему данные в таблице дублируются — это особенность модуля или неправильная настройка?
2019-02-20 14:42:11.935745 | 8001 | 0 | 0
2019-02-20 14:42:11.947698 | 8001 | 0 | 0
2019-02-20 14:43:12.093285 | 721 | 5 | 1
2019-02-20 14:43:12.093285 | 722 | 4 | 1
2019-02-20 14:43:12.093285 | 723 | 3 | 1
2019-02-20 14:43:12.093285 | 724 | 2 | 1
2019-02-20 14:43:12.105338 | 721 | 5 | 1
2019-02-20 14:43:12.105338 | 722 | 4 | 1
2019-02-20 14:43:12.105338 | 723 | 3 | 1
2019-02-20 14:43:12.105338 | 724 | 2 | 1
2019-02-20 14:43:13.227364 | 8001 | 0 | 0
2019-02-20 14:43:13.23936 | 8001 | 0 | 0
2019-02-20 14:44:12.180286 | 721 | 5 | 1
2019-02-20 14:44:12.180286 | 722 | 4 | 1
2019-02-20 14:44:12.180286 | 723 | 3 | 1
2019-02-20 14:44:12.180286 | 724 | 2 | 1Думаю, нужно начать с настройки опроса по триггеру. А затем перейти к написанию запросов и хранимых процедур для работы с Вашей БД
Спасибо за совет. С триггерами всё понятно, с БД не совсем. Сможете подсказать, где устанавливается период выполнения запросов у модуля экспорта в БД? И правильно ли я понял, что вызов запроса, записанного в модуле, выполняется по периоду и при изменении данных?
В моём случае, я пока-что не могу найти решения кода хранимой процедуры из-за того, что значение канала триггера раньше записывается в БД, чем данные других каналов. Соответственно, я не могу в теле процедуры взять нужные значения каналов и поместить в мою таблицу т.к. их еще нет. Но это, я думаю, вопрос больше к СУБД=)
ПЛК имел специальный тег — триггер. Когда этот тег становился 1 на несколько секунд, то с помощью Модуля автоуправления выдавалась команда на считывание измерений. Измерения Коммуникатор передавал на SCADA-Сервер как обычно.
Не до конца понимаю, как заставить Уоммуникатор опрашивать существующий КП только по триггеру с модуля и только один раз. Если где-то есть документация по этому поводу, буду безмерно признателен.
Но дальше начиналось то, что выходит за рамки SCADA. С помощью модуля экспорта в БД все измерения передавались в специально разработанную базу данных, где уже структурировались и обрабатываклись по логике базы.
Я правильно понимаю, что, например, если я с помощью модуля БД буду записывать данные в таблицу, для которой установлен уникальный первичный ключ, то я получу в БД только уникалььные данные по одному из параметров с кучей ошибок о попытках вставить дублирующие данные? Т.е. это решит мою задачу, я прав?
Если у Вас у панели только 1 параметр — её вес, то можно и без БД обойтись. Писать просто в события Rapid SCADA. Но потребуется разработать свой модуль для SCADA-Сервера, который будет писать события по заданной логике.
Есть ли где-то подробный материал по работе с событиями и ТУ?
На самом деле моя задача сводиться не к получению в скада нужного формата данных, а их выгрузке из скады в 1С в таком формате. Т.е. отображаться в вебе и в бд скады могут и сырые данные, а выгрузить их нужно в нужном формате любым способом, т.к. запихать их в 1С уже не проблемма, но желательно не парсить на стороне 1С. Может вы мне подскажете в какую сторону мне тогда проще будет смотерть?
Отчет по изменению ? а если две панели оказались с одинаковыми параметрами ? Что дубль а что не дубль ?
Для этого мне и нужен счетчик отвесов, по которому можно точно понять где какая. Так-же, как и регистры со стабилизацией веса и весом нетто, чтобы понять, когда мы уже всё взвесили.
что используя готовые весовые контроллеры будьте готовы, что придется писать драйвер на него. У них кажется частенько далеко не Modbus протоколы.
Специально смотрю те, у которых он есть, чтобы еще глубже не зарываться в песок=)
Единственное, что нет уверености, что я смогу от них добиться, чтобы он в нужный мне момент ножкой дёргал для включения периферии, поэтому и смотрел в сторону модуля автоматического управления.Есть более детальное описание тех процесса ? так будет проще помочь..
Задача во взвешивании выходящих со станка панелей. Для этого планируется собрать стол с вытяжными роликами и концевиками. Сам процесс взвешивания хотел решить с помощью уже готовых весовых контроллеров(видется мне это проще и дешевле, чем покупать плк+модуль преобразования сигналов тензодатчиков+табло для отображения последнего веса), но у них довольно захардкоженное поведение. Есть в некоторых счетчики и регистры, хранящие последние измерения, но это все равно будет спамом в скаду одиннаковых данных. С tcp пока что дел не имел и думал всё делать на 485 из-за простоты.
Ну а если данные будут одиннаковые, то есть в скаде возможность построить отчёт по ним, минуя дубли?
