Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.

Сообщения - atg

Страницы: [1]

Ваши вопросы / Re: Работа системы архивирования данных

« : 17 Марта 2017, 16:26:06 »

Цитата: Simple-Scada от 17 Марта 2017, 15:45:30

Цитировать
Ну мне кажется в этом и суть "комбинированной" переменной писать и так и так, мало ли для чего это нужно инженеру.
Нет, суть комбинированного способом в том, что он работает как способ "по-времени" + как способ "по-изменению".

Я это и имел ввиду. И согласно документации я ожидал от нее именно такого поведения. А получилось, что вы "улучшили" ее функционал, не написав об этом нигде. В итоге, столкнувшись с поведением переменной отличном от описанного в документации, и стали возникать вопросы. Зачем в документации писать "рекомендуется выставить интервал 1 час" и при этом втихую сделать это самим.

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

Лично мне частая запись не нужна, мне нужно просто посчитать время во включенном состоянии (1). Но пытаясь выдергивать значения из базы я увидел, что время их записи отличается от описанного в документации, и на основании этого родились сомнения - а все ли здесь работает корректно? а может какие-то данные теряются? Было бы написано "архивируется раз в час" я бы и не стал парится..

А вообще simple scada мне нравится

Ваши вопросы / Re: Работа системы архивирования данных

« : 17 Марта 2017, 15:10:29 »

Цитата: Simple-Scada от 15 Марта 2017, 15:56:16

Цитировать
2. Почему игнорируется интервал архивирования из настроек? Стоит например 10 сек., а для комбинированной переменной запись происходит через час.
Переменная долго находится в одном состоянии? Если да, то скада не будет добавлять одно и то же значение каждые 10 сек, т.к. это ничего не изменит ни на тренде, ни при расчетах с учетом времени.

Ну мне кажется в этом и суть "комбинированной" переменной писать и так и так, мало ли для чего это нужно инженеру. Рекомендации про 1 час в руководстве у вас даны. Для чего насильно изменять при этом интервал (нигде про это не упоминая) не понятно и вводит в заблуждение.

Цитировать

Да, данные накапливаются в буферы и сбрасываются на жесткий диск каждые 5 минут (для основного слоя), поэтому в случае аварийного потеряется не более 5 мин. основного слоя. Минутный слой сбрасывается каждую минуту, часовой - час, суточный - день. Для часового и суточного слоев делается резервная копия каждые 10 минут и в случае сбоя данные из резерва будут восстановлены после очередного запуска сервера.

К сожалению это не всегда так. Проведенный эксперимент (комбинированная переменная):
17.59
mysql> select * from trends_data where id=13 order by timestamp desc limit 3;
+----+-------------------------+-------+---------+
| ID | Timestamp | Value | Quality |
+----+-------------------------+-------+---------+
| 13 | 2017-03-17 17:50:33.573 | 1 | 1 |
| 13 | 2017-03-17 16:56:09.611 | 0 | 2 |
| 13 | 2017-03-17 16:54:28.553 | 1 | 1 |

18.00 Стоп и последующий старт проекта через сервер
mysql> select * from trends_data where id=13 order by timestamp desc limit 3;
+----+-------------------------+-------+---------+
| ID | Timestamp | Value | Quality |
+----+-------------------------+-------+---------+
| 13 | 2017-03-17 17:50:33.573 | 1 | 1 |
| 13 | 2017-03-17 16:56:09.611 | 0 | 2 |
| 13 | 2017-03-17 16:54:28.553 | 1 | 1 |

quality = 3 нету.
Последние значения из trends_minute, trends_hour, trends_day точно такие же.

18.57 (прошел почти час)
Последние значения из всех таблиц trend_data trends_minute, trends_hour, trends_day точно такие же, новых записей нет.

19.03 (прошло больше часа)
в trends_data появилось значение за 18.00
mysql> select * from trends_data where id=13 order by timestamp desc limit 3;
+----+-------------------------+-------+---------+
| ID | Timestamp | Value | Quality |
+----+-------------------------+-------+---------+
| 13 | 2017-03-17 19:00:14.584 | 1 | 1 |
| 13 | 2017-03-17 18:00:09.885 | 1 | 2 |
| 13 | 2017-03-17 17:50:33.573 | 1 | 1 |
+----+-------------------------+-------+---------+

Ваши вопросы / Работа системы архивирования данных

« : 15 Марта 2017, 15:43:32 »

Здравствуйте.
Версия 2.2. Проект запущен без клиента (через сервер). Есть нарекания к работе системы архивации.

1. Есть переменные с типом архива "комбинированный". вот значения в базе

Код

| 13 | 2017-03-15 06:54:01.157 |     0 |       1 |
| 13 | 2017-03-15 06:54:01.147 |     1 |       1 |
| 13 | 2017-03-15 06:41:21.563 |     1 |       1 |
| 13 | 2017-03-15 06:41:21.553 |     0 |       1 |
| 13 | 2017-03-15 06:04:44.141 |     0 |       1 |
| 13 | 2017-03-15 06:04:44.131 |     1 |       1 |
| 13 | 2017-03-15 05:55:10.391 |     1 |       1 |
| 13 | 2017-03-15 05:55:10.381 |     0 |       1 |
| 13 | 2017-03-15 05:04:41.766 |     0 |       1 |
| 13 | 2017-03-15 05:04:41.756 |     1 |       1 |
| 13 | 2017-03-15 04:50:16.594 |     1 |       1 |
| 13 | 2017-03-15 04:50:16.584 |     0 |       1 |
| 13 | 2017-03-15 03:54:43.891 |     0 |       1 |
| 13 | 2017-03-15 03:54:43.881 |     1 |       1 |
| 13 | 2017-03-15 03:41:59.157 |     1 |       1 |
| 13 | 2017-03-15 03:41:59.147 |     0 |       1 |
| 13 | 2017-03-15 03:02:12.766 |     0 |       1 |
| 13 | 2017-03-15 03:02:12.756 |     1 |       1 |
| 13 | 2017-03-15 02:50:57.110 |     1 |       1 |

Зачем-то перед измененным состоянием дублируется предыдущее.

2. Почему игнорируется интервал архивирования из настроек? Стоит например 10 сек., а для комбинированной переменной запись происходит через час.

3. Я так понимаю сервер не пишет сразу данные в БД, а кэширует данные и пишет их по наступлению какого-то события. Это может привести к потере данных в случае аварийного завершения сервера. Не зафиксируется даже значение на момент старта проекта. Например (для комбинированной переменной) наблюдал такую ситуацию:
16:00 (условно) переменная меняет значение 0->1. Происходит запись.
16:01 выключение проекта.
16:02 изменения значение переменной 1->0 (не через скаду)
16:03 старт проекта.
17:00 (прошел почти час) аварийное завершение сервера.
В итоге в БД нет ни одного значения начиная со старта сервера. Даже не зафиксировано значение переменной с quality = 2.

4. Пару раз проскочила такая ошибка. Между 16:04 и 15:41 была остановка проекта (через кнопку стоп на сервере), но значения переменной с quality = 3 записано не было:

Код

| 16 | 2017-03-15 16:45:40.603 |     0 |       3 |
| 16 | 2017-03-15 16:04:20.511 |     0 |       2 |
| 16 | 2017-03-15 15:41:16.548 |     0 |       1 |
| 16 | 2017-03-15 15:41:16.538 |     1 |       1 |

Ваши вопросы / Re: Интервал записи трендов в БД

« : 10 Марта 2017, 15:39:20 »

Обновил. Теперь повторяющихся значений нет. Спасибо.
Quality 2- это я так понимаю значение при запуске клиента, а 3 - при выходе?

Ваши вопросы / Re: Интервал записи трендов в БД

« : 10 Марта 2017, 14:29:42 »

Отправил

Ваши вопросы / Re: Интервал записи трендов в БД

« : 10 Марта 2017, 12:39:26 »

ну и очень странно выглядит одинаковый интервал записи этих значений - ровно 2:40, иногда 3:20
15:36:50      0:02:40
15:34:10      0:02:40
15:31:30      0:03:20
15:28:10      0:02:40
15:25:30      0:02:40
15:22:50      0:02:40
15:20:10      0:03:20
15:16:50      0:02:40
15:14:10      0:02:40
15:11:30      0:02:40
15:08:50      0:03:20
15:05:30      0:02:40
15:02:50      0:02:40
15:00:10      0:02:40

Ваши вопросы / Re: Интервал записи трендов в БД

« : 10 Марта 2017, 12:29:24 »

Цитата: Simple-Scada от 10 Марта 2017, 12:10:53

Т.е. каждые 10 сек. будет добавляться новая запись с отметкой времени и значением, хотя скада не получала от OPC-сервера значение с такой отметкой времени и значением и оно может быть уже другим, или с другим качеством, мало ли по каким причинам OPC-сервер не прислал значение.

в логах OPC-сервера я вижу что эти данные опрошены с тем же интервалом, что и те, которые записаны часто.

Цитировать

Если это мешает Вам при визуализации тренда и он состоит из больших диагоналей, то можно изменить тип отрисовки тренда на "Ступенчатый".

Мне это нужно для того, чтобы удостоверится что в БД нет выпадающих данных.

Ваши вопросы / Интервал записи трендов в БД

« : 10 Марта 2017, 11:55:58 »

Здравствуйте.
В БД записываю 6 трендов. 2 из них меняются часто, 4 редко. Интервал записи в настройка стоит 10сек. Данные, которые меняются часто, записываются как положено 10сек+-2 сек. Данные которые меняются редко записываются как-то странно с интервалом 2м40сек. Так и должно быть или где то ошибка?
Что такое Quality ?
mysql> select * from trends_data where id=13 order
+----+-------------------------+-------+---------+
| ID | Timestamp | Value | Quality |
+----+-------------------------+-------+---------+
| 13 | 2017-03-10 15:36:50.005 | 1 | 1 |
| 13 | 2017-03-10 15:34:10.013 | 1 | 1 |
| 13 | 2017-03-10 15:31:30.008 | 1 | 1 |
| 13 | 2017-03-10 15:28:10.003 | 1 | 1 |
| 13 | 2017-03-10 15:25:30.003 | 1 | 1 |
| 13 | 2017-03-10 15:22:50.007 | 1 | 1 |
| 13 | 2017-03-10 15:20:10.017 | 1 | 1 |
| 13 | 2017-03-10 15:16:50.001 | 1 | 1 |
| 13 | 2017-03-10 15:14:10.031 | 1 | 1 |
| 13 | 2017-03-10 15:11:30.003 | 1 | 1 |
| 13 | 2017-03-10 15:08:50.004 | 1 | 1 |
| 13 | 2017-03-10 15:05:30.000 | 1 | 1 |
| 13 | 2017-03-10 15:02:50.000 | 1 | 1 |
| 13 | 2017-03-10 15:00:10.049 | 1 | 1 |
| 13 | 2017-03-10 14:57:30.007 | 1 | 1 |
| 13 | 2017-03-10 14:56:13.578 | 1 | 1 |
| 13 | 2017-03-10 14:56:10.011 | 0 | 1 |
| 13 | 2017-03-10 14:54:40.010 | 0 | 1 |
| 13 | 2017-03-10 14:52:00.008 | 0 | 1 |
| 13 | 2017-03-10 14:49:25.293 | 0 | 1 |
+----+-------------------------+-------+---------+

Страницы: [1]