roboforum.ru

2SMT: Реально не понятно что и как в вашей программе можно привести скриншот с какой-то программкой и указать, какие блоки что означают?

можно привести скриншот с какой-то программкой и указать, какие блоки что означают?

Думаете поможет?
Там стековая машина - сначала запихиваешь аргументы, потом вызываешь функцию.
Ход выполнения программы - это тайна покрытая мраком... Оно конечно событийное, только кубики
стоят в строгом беспорядке... "Соединение" и "объединить" вообще убили...

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

Обратите внимание это ЛИНЕЙНЫЕ два события Без циклов, без ветвлений...

Интуитивная понятность даже у текста выше, имхо,
Старт
=====
Мотор1.ПолныйВперед
Мотор2.ПолныйВперед

Бампер
======
Мотор1.ПолныйНазад
Мотор2.ПолныйНазад
Пауза 2 секунды
Мотор1.ПолныйВперед
Мотор2.ПолныйВперед

Суровая штука понять то я понял, но вот вопрос - школьникам есть смысл выносить мозг стековой машиной?

Сделал пару демок с использованием встроенной "симуляции"
Использование переменной

Передача значения мощности моторам и их остановка по сигналу нажатия на бампер


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


Добавлено спустя 13 минут 27 секунд:
Программа сырая, но для обкатки решения достаточна. Предлагаю раскритиковать нафиг неудачные решения и предложить улучшения или альтернативу.

+1. Вынос мозга...

2SMT: Я понимаю как это работает, а вот школьникам ИМХО будет очень тяжко. Не ясно как между собой перекликаются две ветки исполнения программы. Ну и самое главное - не ясно как с этого переходить позже на обычный язык

Насчет веток была мысль переделать (в Lego аналогично вроде сделано). Общее поле сделать в виде таб-контрола, в каждой вкладке (табе) на входе только одно событие. Например, вкладка для обработки сигнала одного бампера (для другого - вторая вкладка), кнопки "пуск", таймера и т.п. Сервисы (датчики), поставляющие события (и\или данные) проверять по очереди (вытесняющая многозадачность, как в Win3.1), или по прерываниям (учитывая приоритеты).

Добавлено спустя 3 минуты 2 секунды:
Каждый блок может быть транслирован в код (видимый в специальном окне по блокам или с подсветкой фрагмента при выборе блока) - этот код потом можно собрать в программу и скомпилировать.

if-ы у меня пока не работают на else, есть и другие незавершенности. Вопрос в принципиальном решении

2SMT:

А что именно предлагается взять из этого решения?

1. Визуальное решение явно надо менять.

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

3. Настройка "кубика" - ну это понятно, что надо;

но в случае событийной ориентированности надо вводить веревки данных,

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

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

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

Есть мысли что можно изменить в визуальном плане, чтобы было ясно и понятно?

Нужно иметь прямой, мало разветвляющийся и явно глазами видимый путь - ход выполнения программы.
Действия укрупнить. Например, вместо отдельного задавания данных, можно в кубике мотор завести
ТекстБокс "скорость". Любая структура должна быть "монолитной" - не надо ее разбивать на куски!

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

Без переменных (глобальных) не обойтись

Я и не спрашивал о переменных, я спрашивал о "веревках".

Michael_K писал(а):Какая связь между событийностью и веревками данных?

Такая, что там очень часто переменные используются ровно 1 раз, а значит есть смысл просто соединить выход со входом, не вводя именование.

Добавлено спустя 7 минут 14 секунд:

SMT писал(а):Есть мысли что можно изменить в визуальном плане, чтобы было ясно и понятно?

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

Michael_K писал(а):Действия укрупнить. Например, вместо отдельного задавания данных, можно в кубике мотор завести ТекстБокс "скорость"

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

=DeaD= писал(а):есть смысл просто соединить выход со входом

так я и сделал - в блоке есть значение Value set и get, которое может потребляться (использоваться блоком), передаваться дальше неизменным (если это логично), или измененным (в вычисляемом блоке).

=DeaD= писал(а):Отвязаться от строгих позиций "кубиков"

Думаю будет больше вероятность запутать программу

2SMT: Так как насчет событийной-ориентированности? Отказаться есть планы? Или при переводе в обычный язык всё-таки делать невидимый главный цикл и всё такое?

Поскольку у нас есть множество независимых датчиков, событийная ориентированость упрощает понимание. В реальной программе для МК его можно скрыть циклом с опросом датчиков и подключение датчиков к прерываниям, но в среде разработки подобного обобщенного представления подробности разумно скрывать. Не знаю как можно сделать проще.