roboforum.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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