Подскажите идею, алгоритм. Управление с запаздыванием.

← →
OW © (2011-10-25 08:53) [0]

Приветствую!

Имеется в БД около 20 000 логических устройств(пусть Ci i=1-20000).
Каждое устройство имеет минимум один датчик, максимум два. Каждый датчик может быть в состоянии 1,0. В БД, триггерами и хранимками, в процессе работы моей замечательной шараги все датчики красиво показывают идеальную картину. (на form1 вывожу на канву красно-зеленые точки).
Проблем бы не было, если эту логическую схему не нужно было бы перенести на реальные физические устройства :)

Процесс переноса (подачи команды) происходит так:
В текстовый файл пишется максимум 100 команд, и выкладывается в определенное место. Как только передатчик освободится он этот файл заглатывает, стирает и начинает передавать.

Команда включает в себя
id устройства, id датчика (1й или, если есть, 2й), включить/выключить
например
..
12345,1,1
7058,2,0
..

Задача поддержать максимально близко реальное состояние прототипу в БД.

Проблема.
Бывает, за сутки перещелкиваний столько, что передатчик не успевает рассылать команды. Как бы, ничего страшного, такое не часто, нагонит в след.день.

Часто случается так, что устройство щелкнуло в 1, команда забуферезировалась в таблицу(100 команд максимум, как сейчас сделано - лишние просто пишутся в таблицу), прошло время, устройство щелкнуло в 0, забуферезировалось.
т.е. передатчик когда нибудь пошлет команду включить, потом выключить, а мог бы ничего уже не делать! :) т.е. картина и так уже соответствует реальности.

Все это Устройство-Датчик1[-Датчик2] - упрощение. Таблиц таких нет.
Есть открытая функция GetOFF(время1-время2) - дает таблицу вида
idУстройства-Датчик-время выключения
..
12345,1,datatime1
7058,2, datatime2
..
т.е. те устройства и датчики, которые были выключены в этот промежуток
Есть обратная, аналогичная,GetON(время1-время2)
устройства и датчики, которые были включены в этот промежуток

Надо
повторюсь,
поддержать максимально близко реальное состояние прототипу

зы
зря я наверное про таблицу-буфер команд сказал - возможно зашорил ветку идей :)

← →
sniknik © (2011-10-25 10:01) [1]

> стирает и начинает передавать.
вот это ИМХО узкое место, классика клиент-сервера подразумевает запрос клиента к серверу когда нужно, а не посылки сервером клиентам надо это или нет...

не нужно ничего посылать, нужно просто менять статус и ничего больше не делать, а когда нужно отобразить состояние (стопицотразвсекуду обычно лишнее, человек не уследит) допустим раз в минуту, клиент читает ему нужное.

← →
oldman © (2011-10-25 10:01) [2]

> Часто случается так, что устройство щелкнуло в 1, команда
> забуферезировалась в таблицу(100 команд максимум, как сейчас
> сделано - лишние просто пишутся в таблицу), прошло время,
> устройство щелкнуло в 0, забуферезировалось.
> т.е. передатчик когда нибудь пошлет команду включить, потом
> выключить, а мог бы ничего уже не делать!

Пошел в туалет, включил свет, сходил - выключил.
А ведь мог и не включать!!!

← →
sniknik © (2011-10-25 10:11) [3]

> Пошел в туалет, включил свет, сходил - выключил.
> А ведь мог и не включать!!!
у него проблема не в том что событие лишнее, а в "лишнести" его обработки, грубо говоря охранник пытается контролировать каждое действие, и в туалетах тоже, по включению/выключению света. а что реально ему нужно так это просто знать текущее состояние в какой то определенный момент. например в конце рабочего дня, знать что нужно обесточивать.

т.е. пытается работать с событиями, хотя нужно просто проверять статус.

← →
OW © (2011-10-25 10:24) [4]

да. нужно стараться поддерживать реальную картину.
Сходил в туалет без света - молодец. Но зачем там включать выключать свет уже потом, когда там нет никого..

Еще момент, очень важный - устройства обратной связи не имеют.
т.е. послать ему команду можно, оно ее (_возможно_) выполнит, но получить состояние устройства нет возможности.
Поэтому, когда передатчик свободен, ему командуют то, что уже когда-то командовали. Так сказать, повторяем. (Команда по радио идет, а устройство могло быть экранировано, выключено из 220, иной сбой)

← →
OW © (2011-10-25 10:25) [5]

> вот это ИМХО узкое место

ты прав.
Техника времен 60х-70х годов. А что делать, надо что бы работало :)

← →
sniknik © (2011-10-25 10:29) [6]

> но получить состояние устройства нет возможности.
нельзя от устройства получай от того кто им управляет. или меняй им (в "управлятеле") статус-поле в базе, главное не пытайся работать/отображать по данным от этих управляющих событий.

← →
sniknik © (2011-10-25 10:32) [7]

> А что делать, надо что бы работало :)
сделай чтобы "записывало в общий реестр по устройствам, и стирало, но не передавало"

← →
OW © (2011-10-25 11:39) [8]

перечитал, похоже есть непонятки (на всякий случай и это скажу тоже. не надо визуализировать ничего, надо командовать.)

итого думаю так передалать.
есть job.

job вызывает GetOFF(времяПоследнего своего запуска - now)
заполняет буффер
GetON(времяПоследнего своего запуска - now)
заполняет буффер.

На вставке триггер, если устройство и датчик уже в таблице есть - удалить такую команду, вставить новую.

второй job мониторит отсутствие файла и из этого буфера подкармливает передатчик новыми порциями по 100 команд. Скормленные команды удаляем.

Как сюда повторы воткнуть бы половчее?

← →
Sha © (2011-10-25 11:47) [9]

> поддержать максимально близко реальное состояние прототипу

По включенным или по выключенным устройствам?
Например, горит половина лампочек, но должна гореть другая половина.
Какие команды надо выдать в этом случае?

Есть ли статистика по требуемому времени горения/негорения?
Надо ли обеспечить дисциплину LIFO/FIFO для команд?

Почему через файл, а не TCP?

← →
sniknik © (2011-10-25 11:49) [10]

> похоже есть непонятки
при описании "в общем, не реального" не удивительно.

> удалить такую команду, вставить новую.
нафига? почему не -
обновить статус датчика если он есть, добавить новый со статусом если его нет.
зачем удалять/делать "тяжолые" с реиндексом (если он есть) команды при общей "борьбе за скорость"...

через какое то время будешь только обновлять... быстро. все датчики будут "в наличии".

← →
Sha © (2011-10-25 11:59) [11]

Таблица состояний каждой лампочки (текущего и требуемого)
лежит в памяти управляющей программы, копия - в БД.
Обходим ее по циклу и в случае несовпадения состояний
выдаем команду по TCP.

← →
Плохиш © (2011-10-25 12:05) [12]

> OW © (25.10.11 08:53)

Создаётся таблица требуемых состояний датчиков. Кому надо пишет туда требуемые на момент состояния датчиков. Передатчик тупо по таймеру (или какой там у вас критерий) стирает файл командч берёт состояния из таблицы и пишет по ним команды в файл.

← →
OW © (2011-10-25 12:06) [13]

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

надо потушить первые и зажечь вторые

> Есть ли статистика по требуемому времени горения/негорения?

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

> Надо ли обеспечить дисциплину LIFO/FIFO для команд?
нет.

> Почему через файл, а не TCP?
потому что старое оборудование. Так написано в доке, вообщем. И про другие варианты нет ничего.

---

> > удалить такую команду, вставить новую.
> нафига? почему не -
> обновить статус датчика если он есть, добавить новый со
> статусом если его нет.
> зачем удалять/делать "тяжолые" с реиндексом (если он есть)
> команды при общей "борьбе за скорость"...

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

~ 20 000 устройств, это ерунда. Самая загвоздка в файле. За время, пока его оборудование обработает, можно переиндексировать несколько раз все.

← →
Плохиш © (2011-10-25 12:08) [14]

> потому что, если пусть идут команды включить-выключить-включить-
> команда конечному устройству должна быть включить.

В файле должна быть только одна команда для устройство. Все предыдущие стереть не задумываясь :-)

← →
OW © (2011-10-25 12:10) [15]

> Плохиш © (25.10.11 12:05) [12]

Тогда и получится, как сейчас

> идут команды включить-выключить-включить- команда конечному
> устройству должна быть включить. Нет смысла его включить-
> выключить-включить, все равно он включенный будет после
> этой серии

т.е. из 100 команд 3 уже потрачены, вместо одной. Это значит, что 2 полезные команды не выполнены. А это значит, что реальное состояние 2х других устройств, не попавших в эту сотню, будет изменено только в следующий проход.

← →
OW © (2011-10-25 12:16) [16]

> обновить статус датчика если он есть, добавить новый со
> статусом если его нет.
> зачем удалять/делать "тяжолые" с реиндексом (если он есть)
> команды при общей "борьбе за скорость"...
>
> через какое то время будешь только обновлять... быстро.
> все датчики будут "в наличии".
> <Цитата>
>
> Sha © (25.10.11 11:59) [11]
>
> Таблица состояний каждой лампочки (текущего и требуемого)
> лежит в памяти управляющей программы, копия - в БД.
> Обходим ее по циклу и в случае несовпадения состояний
> выдаем команду по TCP.

ну, в общем, одно и тоже..
ну да, или так.

только без TCP :)

← →
Плохиш © (2011-10-25 12:17) [17]

> т.е. из 100 команд 3 уже потрачены, вместо одной.

В одном файле только одна команда для устройства.
Не отправленные файлы перезаписываются без сожаления.
Команды создаются для состояний из таблицы.
Никаких последовательностей команд.
И никаких проверок [11] ибо отсутствует обратная связь.

← →
OW © (2011-10-25 12:39) [18]

запутался..

> отсутствует обратная связь.

да.
[11] - наверное не то..

таблица. Там копятся команды. триггером дубли УСтройство-датчик убираются.
т.о. в таблице только реальные команды, которые надо выполнить.
вводим поле. [сколько раз командовали] тех, кого выгружаем - inc этому полю.
выгружаем тех, у кого это поле минимально.

т.е. select top 100 order by [сколько раз командовали]
в файл
inc [сколько раз командовали]

пришла новая команда - затерли старую, [сколько раз командовали] = 0

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

вроде, правильно..

← →
sniknik © (2011-10-25 12:42) [19]

> И никаких проверок [11] ибо отсутствует обратная связь.
кто последний тот и прав... тоже классика.

> вроде, правильно..
не правильно ибо сложно... логика должна быть как можно более простой.

усложнять просто, упрощать сложно...

← →
Плохиш © (2011-10-25 12:52) [20]

> таблица. Там копятся команды. триггером дубли УСтройство-
> датчик убираются.
> т.о. в таблице только реальные команды, которые надо выполнить.
>
> вводим поле. [сколько раз командовали] тех, кого выгружаем
> - inc этому полю.
> выгружаем тех, у кого это поле минимально.
>
> т.е. select top 100 order by [сколько раз командовали]
> в файл
> inc [сколько раз командовали]
>
> пришла новая команда - затерли старую, [сколько раз командовали]
> = 0
>

Что-то сложно :-(
Кого интересует [сколько раз командовали]? Интересно только требуемое состояние.

← →
Плохиш © (2011-10-25 12:55) [21]

Не знаю нафига там бд, нужен всего один одномерный массив битов и из него блоками генерировать команды.

← →
Sha © (2011-10-25 13:26) [22]

Отслеживаем удаление файла.
Файл исчез - создаем и кладем в него всегда одну команду включения/выключения.
Повторяем.

Все храним в памяти.

Для каждой лапочки храним предыдущее и текущее состояние,
а также номер команды, по которой она изменила состояние.

Состояние лампочек:
-1 выкл
0 неизв (начальное знач)
+1 вкл

Нач знач номера команды для лампочки равно ее номеру,
нач знач счетчика команд = колву лампочек.

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

> Для каждой лапочки храним предыдущее и текущее состояние

Филосовски бессмысленная информация, т.к. узнать состояние лампочки невозможно по условию задачи.

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

Преоесть алгоритма в том, что он не выдает ни одной лишней команды на переключение, а когда переключать нечего в цикле повторяет команды для всех лампочек.

Под предыдущим состоянием имеется в виду состояние, которое, по мнению управляющей программы, лампочка будет иметь после выполнения команды управляющей программы.

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

> Sha © (25.10.11 13:26) [22]
>
> Отслеживаем удаление файла.
> Файл исчез - создаем и кладем в него всегда одну команду
> включения/выключения.
> Повторяем.
>
> Все храним в памяти.
>

нет...

1. почему 1 команду, когда можно по 100.

2. Ну и почему в БД хочу.
А если остановимся, сбой или что-то, потом запустимся с того же состояния, прочитав табличку.

Вообще больше заявлено команд, но приписка есть, стараться не больше 100, т.к. были случаи, когда передатчик от большого кол-ва команд переставал передавать вообще.

Экспериментально так понял, ему все равно сколько команд за один раз, если меньше 100
Файл исчезает практически независимо от кол-ва строк в нем. Хотя, да, чем больше, тем дольше.
на глаз видно, что не выгодно по 1 слать все равно

> OW
> 1. почему 1 команду, когда можно по 100.

А нафиг 100, если есть шанс передать ненужное.
Передаем по 1, только то, что нужно переключить в данный момент.

> на глаз видно, что не выгодно по 1 слать все равно

Ты бы уже давно измерил время передачи пакетов разных длин.
Если время пропорционально колву команд, то надо по 1 передавать,
иначе определи оптимальную длину.
Шли хоть по 100 команд по тому же алгоритму (для 100 самых старых ламп)

> 2. Ну и почему в БД хочу.
> А если остановимся, сбой или что-то, потом запустимся с того же состояния, прочитав табличку.

Одно другому не мешает. Храни в БД копию таблицы из ОП, а в начале работы читай ее.

использовать не 1 файл, а минимум Ci/100
устройства натравливать на свои "файлы" или папки с файлом
1-100=file1.txt
101-200=file2.txt

Подскажите идею, алгоритм. Управление с запаздыванием. Найти похожие ветки