Вверх ↑
Этот топик читают: Гость
Ответов: 537
Рейтинг: 14
#1: 2017-06-08 00:11:19 ЛС | профиль | цитата
Давно пользуюсь во многих своих схемах такой схемой:
Add(MainForm,2953706,21,105)
{
}
Add(MultiElementEx,7508932,133,112)
{
@Hint=#4:Стоп|
AddHint(-5,-28,39,13,@Hint)
}
BEGIN_SDK
Add(EditMultiEx,2251604,21,21)
{
WorkCount=#21:1 Да=Пропускать далее|18:0 Нет=Непропускать|10:Да или Нет|
EventCount=#8:Выход Да|
Width=160
Height=123
link(1 Да,1931049:doText,[(31,27)(31,48)])
link(0 Нет,507225:doText,[(31,34)(31,69)])
link(Да или Нет,6407972:doData,[(56,41)(56,90)])
}
Add(Case,6158180,133,84)
{
Value=Integer(1)
link(onTrue,2251604:Выход Да,[(173,97)(173,27)])
}
Add(DoData,6407972,91,84)
{
link(onEventData,6158180:doCase,[])
link(Data,5524065:Value,[])
}
Add(VisualStrings,1931049,42,42)
{
Lines=#1:1|
Width=18
Point(doText)
Point(onText)
link(onText,5905813:doEvent1,[])
}
Add(Hub,5905813,70,42)
{
InCount=2
OutCount=1
link(onEvent1,5524065:doValue,[])
}
Add(VisualStrings,507225,42,63)
{
Lines=#1:0|
Width=18
Point(doText)
Point(onText)
link(onText,5905813:doEvent2,[(65,69)(65,55)])
}
Add(Memory,5524065,91,42)
{
Default=Integer(1)
}
END_SDK

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

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

А еще такая схема с передачей данных:
Add(MainForm,2953706,21,105)
{
}
Add(MultiElementEx,7508932,168,133)
{
@Hint=#4:Стоп|
AddHint(-5,-28,39,13,@Hint)
}
BEGIN_SDK
Add(EditMultiEx,2251604,21,21)
{
WorkCount=#21:1 Да=Пропускать далее|18:0 Нет=Непропускать|10:Да или Нет|
EventCount=#8:Выход Да|
Width=202
link(1 Да,1931049:doText,[(31,27)(31,48)])
link(0 Нет,507225:doText,[(31,34)(31,69)])
link(Да или Нет,10958284:doEvent1,[(56,41)(56,83)])
}
Add(Case,6158180,133,84)
{
Value=Integer(1)
link(onTrue,13584629:doData,[(171,97)(171,164)(79,164)(79,174)])
}
Add(DoData,6407972,91,84)
{
link(onEventData,6158180:doCase,[])
link(Data,5524065:Value,[])
}
Add(VisualStrings,1931049,42,42)
{
Lines=#1:1|
Width=18
Point(doText)
Point(onText)
link(onText,5905813:doEvent1,[])
}
Add(Hub,5905813,70,42)
{
InCount=2
OutCount=1
link(onEvent1,5524065:doValue,[])
}
Add(VisualStrings,507225,42,63)
{
Lines=#1:0|
Width=18
Point(doText)
Point(onText)
link(onText,5905813:doEvent2,[(65,69)(65,55)])
}
Add(Memory,5524065,91,42)
{
Default=Integer(1)
}
Add(EventFromData,4662164,91,126)
{
}
Add(Hub,10958284,63,77)
{
link(onEvent1,4662164:doData,[(84,83)(84,132)])
link(onEvent2,6407972:doData,[])
}
Add(DoData,13584629,91,168)
{
link(onEventData,2251604:Выход Да,[(180,174)(180,27)])
link(Data,4662164:GetData,[])
}
END_SDK

Редактировалось 2 раз(а), последний 2017-06-08 00:41:57
карма: 4

0
vip
#1.1контекстная реклама от партнеров
Ответов: 4612
Рейтинг: 746
#2: 2017-06-08 10:42:24 ЛС | профиль | цитата
Так, вроде, тоже можно:

Add(MultiElementEx,1651186,413,441)
{
@Hint=#4:Стоп|
AddHint(-5,-28,39,13,@Hint)
}
BEGIN_SDK
Add(EditMultiEx,8667553,21,21)
{
WorkCount=#21:1 Да=Пропускать далее|18:0 Нет=Непропускать|10:Да или Нет|
EventCount=#8:Выход Да|
Width=370
Height=193
link(1 Да,8579406:doOn,[(84,27)(84,69)])
link(0 Нет,8579406:doReset,[(96,34)(96,62)])
link(Да или Нет,4877039:doEvent,[(35,41)(35,104)])
}
Add(Switch,8579406,126,49)
{
DataOn=Integer(1)
DataOff=Integer(0)
Point(doOn)
Point(State)
}
Add(IndexToChanel,4877039,126,98)
{
Point(Index)
link(onEvent2,8667553:Выход Да,[(303,111)(303,27)])
link(Index,8579406:State,[])
}
END_SDK

У меня такой вопрос. С одного события поступают данные. Нужно при получении определенной комбинации из этих данных переключить обработку последующих данных на один участок схемы, по наступлению некоторого условия (напр., по получению всех требуемых данных) - вернуть назад ожидание условной комбинации. При получении другой комбинации - переключить на обработку другому участку схемы.
Если конкретнее - это разбор произвольного протокола из получаемых данных. Я пока делал это путем комбинации IndexToChannel+Memory на точку Index. Занесение индекса события в Memory выполняло такое переключение. Какие ещё существуют способы решения такой задачи (кроме кучи Case на индекс)?
карма: 26

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#3: 2017-06-08 10:55:28 ЛС | профиль | цитата
Netspirit писал(а):
Какие ещё существуют способы решения такой задачи (кроме кучи Case на индекс)?

А StrList с включенными doGetIndex и onGetIndex(или Index) не подходит?

Редактировалось 2 раз(а), последний 2017-06-08 10:57:08
карма: 22

0
Ответов: 4612
Рейтинг: 746
#4: 2017-06-08 10:58:11 ЛС | профиль | цитата
Вариант, конечно. Правда, ещё ж и данные нужно пропускать. То-есть: идут данные с одного события на один участок схемы, по наступлению некоторого условия - с того же события на другой участок. Я тут для пробы себе такой компонентик заделал:
EventSwitch

[Property]
Count=Задает количество событий компонента. Максимальный индекс события будет на 1 меньше этого значения.|1|2

[Methods]
doEvent=Вызывает одно из событий onEvent в соответствии с его текущим индексом (первое событие соответствует индексу 0)|1|
doNext=Увеличивает индекс текущего события. Последующие вызовы doEvent будут вызывать событие onEvent согласно новому индексу. Если текущий индекс равен максимальному, то новый индекс станет 0.|1|
*doPrev=Уменьшает индекс текущего события. Последующие вызовы doEvent будут вызывать событие onEvent согласно новому индексу. Если текущий индекс равен 0, то новый индекс станет равным самому максимальному (Count-1).|1|
*doSetIndex=Установить текущий индекс события значением из потока. Значение не должно превышать максимальный индекс (Count-1)|1|
*Data=Данные, выдаваемые в поток событиями onEvent|4|
CurrentIndex=Текущий номер (индекс) вызываемого события|3|1
Просто подумал, может что-то из существующего пропустил.

Редактировалось 1 раз(а), последний 2017-06-08 11:02:24
карма: 26

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#5: 2017-06-08 11:06:40 ЛС | профиль | цитата
Netspirit писал(а):
Я тут для пробы себе такой компонентик заделал

И где в твоем компоненте блок условий? У тебя обычный переключаемый коммутатор
карма: 22

0
Ответов: 4612
Рейтинг: 746
#6: 2017-06-08 11:32:25 ЛС | профиль | цитата
Так я это и имел в виду - по выполнению некоторых условий я переключаю подачу данных (точнее, события с данными) из одной и той же точки в разные ветки схемы. В IndexToChannel ветка определялась Memory с индексом события. Здесь же два компонента в одном, плюс парочка методов для простого переключения "следующее/предыдущее". Условия могут быть разными, поэтому проверяются в других местах, а точнее - в тех самых ветках, которые в данный момент обрабатывают данные. То-есть, 1-ая ветка получила данные, проанализировала их и переключила обработку на 2-ю ветку. Вторая ветка закончила - переключила обратно на первую, или на третью.
Как я понимаю, это "конечный автомат" или "машина состояний".

Редактировалось 3 раз(а), последний 2017-06-08 11:36:03
карма: 26

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#7: 2017-06-08 12:14:14 ЛС | профиль | цитата
Netspirit писал(а):
То-есть, 1-ая ветка получила данные, проанализировала их и переключила обработку на 2-ю ветку. Вторая ветка закончила - переключила обратно на первую, или на третью.


А чем, в таком случае, не подойдет связка CounterEx и IndexToChannel?
карма: 22

0
Ответов: 4612
Рейтинг: 746
#8: 2017-06-08 12:22:27 ЛС | профиль | цитата
Тоже подходит. Как раз спрашивал, какие есть варианты.
карма: 26

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#9: 2017-06-08 13:06:58 ЛС | профиль | цитата
Netspirit писал(а):
Тоже подходит. Как раз спрашивал, какие есть варианты.

Ты так это интересно спросил, что я фиг сначала понял, что тебе надо. Вот смотри: StrList -- это блок условий, который заменяет кучу Case, и его точку Index можно подать на IndexToChannel для коммутации потоков, но этот вариант не фиксированный. Второй вариант, который с CounterEx, представляет собой шаговый коммутатор, он уже становится фиксированным. И, кстати, оба этих варианта можно каскадировать, если точку onGetIndex StrList-a подцепить на точку doValue CounterEx для прямого управления шаговым коммутатором.

--- Добавлено в 2017-06-08 13:17:57

Не знаю, заметил ты или нет, но с помощь последних версий IndexToXChannel можно программировать максимальное значение CounterEx, те привязать CounterEx к количеству каналов IndexToChannel
Схема

Add(MainForm,2953706,77,175)
{
link(onCreate,8642408:doData,[])
}
Add(CounterEx,229109,203,168)
{
Point(doPrev)
Point(doValue)
Point(doMax)
}
Add(IndexToChanel,1287293,203,231)
{
Point(EndIdx)
Point(Index)
link(Index,229109:Count,[])
}
Add(DoData,8642408,147,189)
{
link(onEventData,229109:doMax,[])
link(Data,1287293:EndIdx,[(153,159)(244,159)(244,271)(209,271)])
}


Редактировалось 2 раз(а), последний 2017-06-08 13:19:10
карма: 22

0
Ответов: 4612
Рейтинг: 746
#10: 2017-06-08 13:21:06 ЛС | профиль | цитата
StrList не нужен. Для проверки условий есть достаточно компонентов. Нужно просто имеющийся один горизонтальный канал с данными (выход события) перенаправлять на обработку в разные участки по принципу IndexToChannel. В комбинации с Memory или CounterEx - подходит.

--- Добавлено в 2017-06-08 13:27:11

nesco писал(а):
но с помощью последних версий IndexToXChannel можно программировать максимальное значение CounterEx
Особого смысла в данном случае не вижу, так как количество выходов фиксированно и известно на момент разработки.

Редактировалось 1 раз(а), последний 2017-06-08 13:27:11
карма: 26

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#11: 2017-06-08 13:27:58 ЛС | профиль | цитата
Netspirit писал(а):
Для проверки условий есть достаточно компонентов

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

--- Добавлено в 2017-06-08 13:32:00

Netspirit писал(а):
Особого смысла в данном случае не вижу, так как количество выходов фиксированно и известно на момент разработки

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

Редактировалось 1 раз(а), последний 2017-06-08 13:32:00
карма: 22

0
Ответов: 4612
Рейтинг: 746
#12: 2017-06-08 14:01:07 ЛС | профиль | цитата
Просто для мысленного эксперимента приведу пример. Есть событие onRead. Оно выдаёт данные (строки) порциями неопредленной длины. Предположим, данные имеют вид:
"<тип данных><длина><разделитель><данные указанной длины>"

Поле <тип данных> всегда 1 байт - равно "0" - строка, равно "1" - файл.
Поле <длина> - число переменной длины, например, "1", "123", "2147483647", поэтому для определения его длины используется <разделитель> (1 байт). Затем идут данные указанной длины и назначения.
Поскольку данные выдаются порциями разной длины, требуется некоторый накопитель (но это другая задача).
Предположим, нам выдались следующие данные:
onRead 1: "0123|данные"
onRead 2: " длиной"
onRead 3: " 123 байта......."

Решается задача с помощью переключателя так:
1) Переключатель в положении 0 (ветка 0) - накапливаем данные до получения разделителя. При получении разделителя: считываем первый символ - получаем "тип данных", считываем символы со 2-го до разделителя - получаем "длину данных", пропускаем один байт разделителя, сохраняем "остаток" после разделителя. По типу данных 0 - переключаем переключатель на ветку 1. По типу данных 1 - переключаем на ветку 2.
2) Переключатель в положении 1 - данные типа "строка". Берем "остаток", полученный в ветке 0 (если есть). Сохраняем. Уменьшаем "длину данных" на длину "остатка". При получении очередного события onRead переключатель направляет полученные данные снова в эту ветку. Если полученные данные больше/равны оставшейся "длине данных":
- скопируем из них первые "длина данных" байт, добавим к уже полученной части строки, сохраним "остаток" в накопителе (ветка 0 должна учесть отданный здесь остаток).
- вся строка нужной "длины" получена. Обрабатываем, как нам нужно.
- переключаем переключатель на ветку 0 - опять ожидаем разделителя
Если полученные данные меньше оставшейся "длины данных":
- присоединяем все текущие данные к ранее полученным
- уменьшаем "длину данных" на полученное количество
- следующее событие опять направит данные в эту ветку переключателем, пока сохраненная "длина данных" не достигнет 0.
3) Ветка 2 - полученный "остаток" и последующие данные являются файлом - открыть файл, сохранять в него все поступающие данные до получения указанной длины, по завершению закрыть файл, переключиться в ветку 0 (ожидание и обработка разделителя), аналогично п.2.

Редактировалось 3 раз(а), последний 2017-06-08 14:05:30
карма: 26

0
Ответов: 16884
Рейтинг: 1239
#13: 2017-06-08 21:39:33 ЛС | профиль | цитата
Прям страшилка какая-то. Как в сказке - чем дальше тем страшней.
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Разработчик
Ответов: 26061
Рейтинг: 2120
#14: 2017-06-08 22:51:05 ЛС | профиль | цитата
Tad писал(а):
Прям страшилка какая-то. Как в сказке - чем дальше тем страшней.

Вот и я тоже почесал репу
карма: 22

0
Ответов: 537
Рейтинг: 14
#15: 2017-06-09 03:35:35 ЛС | профиль | цитата
А откуда эти данные будут получатся? Наверно можно читать число по одному символу, а дальше решать куда обрабатывать. Тут недавно была схема которая читает сиволы по одному и переставляет слова в обратной последовательности. Может подойдет.
Может это интересно, нашел http://forum.hiasm.com/topic/60436
Ещё эта тема http://forum.hiasm.com/topic/65116
А ту что говорил, не нашол. Там тема про слова наоборот

Редактировалось 4 раз(а), последний 2017-06-09 04:30:34
карма: 4

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)