Можете выдать побольше кусок с :f: 2004 .. так оно писать "не может" .. там нельзя выдать болье 255 (в переменную не влезет), и прилепленное число из fadeLED() должно отличаться ровно на 1 в ту или иную сторону..
Можете выдать побольше кусок с :f: 2004 .. так оно писать "не может" .. там нельзя выдать болье 255 (в переменную не влезет), и прилепленное число из fadeLED() должно отличаться ровно на 1 в ту или иную сторону..
Добавил остальные пины на лампы, все отлично работает, пока с одним датчиком! Только вот одна загвоздка, уж очень долго они ВСЕ загораются( не ШИМ, а пауза между лампами) все 6 ламп загораються за 1мин 32сек, долговато! Можно уменьшить? Менял время шим, они просто быстрее загораются, но весь процесс с тем же временем!
1. Да, #define WAIT_1 -- это время паузы между двумя изменениями ШИМ. Если слишком долго, то можно увеличить "шаг" изменений isGo, но тогда его проще выбирать кратным диапазону 0..255. И все сравнения isGo1 == 1/-1 надо будет поменять на величину шага. Проще и правильней завести константу STEP_1 и заменить на неё все +1 и -1 (isGo1 == STEP_1, isGo1 == -STEP_1).
2. Каждая последующая лампа зажигается только после включения предыдущей, что приводит к длительному суммарному времени поджига при больших задержках шага и мелком шаге. Там нет никакой "паузы между лампами". Общее время включения не может быть "одним и тем же".
Играйтесь, подбирайте то, что вам подходит больше всего. Обратите внимание на нелинейность яркости ламп от ШИМ. Видимые изменения яркости ощущаются вовсе не на всем диапазоне 0..255. Может правильнее дополнительно в цикле включения лампы сразу устанавливать начальное значение не в 0, а побольше. Тоже - подбирать только опытным путем, методом "научного тыка". Зависит от типа ламп тоже.
3. Писал, нет? В целях отладки, отключите датчик от платы и сделайте его эмуляцию в программе. Заодно можно закорментарить и его часть setup(). Эмуляция делается просто: заводите статическую переменную uint8_t pirOn=1; перед loop(); в условии проверки комментируете вызов датчика /* */ и вместо него втыкаете pirOn==1. И добавляете внутрь блока команду сброса переменной pirOn=0; все. При первом заходе в loop() проверка "сработал датчик?" даст ответ "да" и сбросит его значение. При последующих заходах - псевдодатчик уже не сработает и Вы можете наслаждаться незамутненным выводом диагностики.
Вы бы выложили окончательный скетч для всеобщего пользования. Платформа Ардуино, всеж-таки предполагает открытую разработку. Вдруг кому ещё пригодится..
я выложу, и видео и все где был и делал! Вдруг кто то не только захочет просто залить скетч, а и понять как он делается и устроен! Ну как я типо!))) Правда я пока еще не особо понял, но... Москва не сразу строилась!
Конечно будут, просто обязательно! Вы же .. учитесь. :)
1 момент: список ламп у вас как был один, так и должен остаться .. но управляться он будет уже из двух ветвей силуэта.
2. Пазуа на выключение .. одна. И точка её старта во времени должна переопределятся ОБОИМИ ветвями (датчиками) заново.
3. Функция fadeLED потребует упрощения. Сейчас она считает текущую задержку для текущей лампы и такая пока .. ОДНА. Как только добавите второй датчик, потребуется считать .. ДВЕ задержки, на каждую из включаемых датчиками ламп (они могут включаться и не синхронно вовсе: 1-й уже догнал до 120, а второй "только начал" включать свою лампу).
4. Попытки включать/выключать одну и ту же лампу (скажем среднюю) двумя алгоритмами .. надо "подсматривать" за текущим индексом второго алгоритма .. дабы не пересечься.
5. Первый датчик выключал .. и тут второй решил пора включать .. остановить бы первый .. :)
В общем, как вижу ничего особо сложного нет, но есть смысл разрисовать ДРАКОН схему и проверить движение сквозь ВСЕ ветки вариаций дотошно. Устранить полностью все коллизии вам все одно не удастся, ибо датчиков только 2, но привести к вполне разумному поведению - можно. :)
Ну .. когда лампы включаются, задается lamp1 = 0, max1 = MAX_LED, так? И далее по коду есть проверка с инкрементом номера лампы lamp1++. И это приводит к тому что начинаем включать с лампы номер 0 (массив с С - всегда начинается с нулевого индекса) и заканчиваем номером MAX_LED-1 (предыдущим от max1) ..
Соответственно, "в обратном" порядке счетчик номера ламп lamp1 надо сразу поставить в последний номер - то бишь "предыдущий" от MAX_LED и последним выключаемым номером будет 0, а стало быть "следующим" будет -1.
Тоесть, если хотим "в том же" порядке, то и надо установить стартовые значение в "тот же порядок" и вместо декремента lamp1-- написать инкремент lamp1++
if( digitalRead(pirPin1) ) //Если датчик №1 сработал то
{
isGo1 = 1; //Включаем лампы (режим датчика №1) с
lamp1=0; // 0 (т.е fadePin1 и далее по порядку )
max1 = MAX_LED; // пока не придем к последней
Вот тут чуть разжувал, ну чтоб мне понятнее было! Правильно?
Почему lamp1 = MAX_LED? MAX_LED ваще-то равно трем, ибо ТРИ лампы .. но нумеруются они с 0 по 2 .. то есть, если хотите включать в порядке 2,1,0 .. надо присваивать MAX_LED-1, нет? :) А проверять до какого значения? :)
Точнее 1 раз оно сработает, поскольку сначала делаем действие с лампой (включаем/выключаем, но я бы хотел посмотреть на тот скетч, с которым Вы сейчас пробуете), если её яркость ещё не достигла предела, а только потом проверяем границу индекса .. и вот тут у вас произойдет "завершение" этого размазанного цикла, ибо lamp1 = MAX_LED-1 = 6-1 = 5 = max1.
Если Вы начинаете с последнего элемента "5", то закончить перебор ламп надо первым элементом с номером "0". А поскольку этот цикл организован по принципу do{}while() (покраска забора), то он сначала исполняет действие с текущим значением счетчика и только потом изменяет его для следующей итерации с проверкой на завершение. Смотрите:
lamp1 = 5 -- устанавливаем ДО начала do{}while(). Далее исполняем тело цикла и изменяем значение на "следующий номер" .. lamp-- .. =4, после чего проверяем .. и повторяем цикл. Получается: 4, это всё? нет: 3, это всё? нет: 2, это всё? нет: 1, это всё?, нет: 0, это всё? ... НЕТ! нам надо ещё вернуться в начало цикла и обработать нулевой элемент массива .. но в конце стоит lamp-- и оно примет значение .. -1. А вот теперь -1, это всё? ДА.
Так чему должно равняться max1, если у нас стоит проверка lamp1 == max1? :)
Похоже я сильно поторопился, объединив в одной проверке несколько разных условий ДРАКОН-схемы. Давайте вернемся чут-чуть назад к ДРАКОН-схеме:
// Схема "Силуэт", состоящая из нескольких ветвей. Правила:
// а) Чем ветка проще и чаще тем левее она на схеме (тут выше - схема повернута "сверху-вниз")
// б) Каждая ветка начинается со своего условия и оно одно.
// в) Переход на следующую ветку - просто завершение блока по if().
// г) Схема перенумерована. Разные датчики - подветки 1,2 соответственно.
// ветка1. "Царская дорога" (самое просто и 3/5 суточного исполнения): Если светло - выходим.
// *прим.: тут надо ещё добавить код, выключающий лампы, если они были ещё включены.
if( isDayNow() ){ /*выключить всё*/ return; }
// ветка2.1 "Темно" - ждем датчик1:
if( digitalRead(pirPin1) ){
isGo1 = 1; // датчик1 сработал: переключаем на ветку 3.1 и подготавливаем данные
lamp1=0; // включение от меньшей к большей, яркость по +1 (isGo1)
max1 = MAX_LED;
}
// ветка2.2 "Темно" - ждем датчик2:
if( digitalRead(pirPin2) ){
isGo2 = 1; // датчик2 сработал: переключаем на ветку 3.2 ..
lamp2=MAX_LED-1; // включение от большей к меньшей, яркость по +1 (isGo2)
max2 = -1;
}
// Разделяем эти условия на отдельные ветки, дабы не путаться:
// ветка 3.1 поштучно включаем лампы от меньшей к большей:
if( isGo1 == 1 ){
// подветка 3.1.1 "текущая лампа уже включена? перейти к следующей"
if( fades[lamp1].bright == 255 ){
lamp1++;
}else{
// ветка "нет" 3.1.1: "добавлять яркость по isGo1, каждые WAIT_1 мсек"
fadeLED(lamp1, isGo1);
}
}
// ветка 3.2. поштучно включаем лампы от большей к меньшей:
if( isGo2 == 1 ){
// подветка 3.2.1 "текущая лампа уже включена? перейти к следующей" порядок обратный! "--"
if( fades[lamp2].bright == 255 ){
lamp2--;
}else{
// ветка "нет" 3.2.1: "добавлять яркость по isGo2, каждые WAIT_1 мсек"
fadeLED(lamp2, isGo2);
}
}
// Ветка 4.1 "Лампы для датчика1 - включили все"? Включаем паузу и переходим к ветке 5.1
if( isGo1 == 1 && lamp1 == max1 ) // мы включали лампы И прошли все?
{
// подветка "ДА" 4.1: "включаем паузу заново, переходим к ветке выключение1"
startedPause = millis(); // фиксируем начало отсчета паузы
isGo1 = -1; // .. после паузы будем выключать (5.1) - меняем направление яркости и шаг
lamp1= 0; // .. снова в порядке от меньшей к большей
max1 = MAX_LED;
}
// Ветка 4.2 "Лампы для датчика2 - включили все"? Включаем паузу и переходим к ветке 5.2
if( isGo2 == 1 && lamp2 == max2 ) // мы включали лампы И прошли все?
{
// подветка "ДА" 4.2: "включаем паузу заново, переходим к ветке выключение1"
startedPause = millis(); // фиксируем начало отсчета паузы
isGo2 = -1; // .. после паузы будем выключать - меняем направление и шаг
lamp2= MAX_LED-1; // .. снова в порядке от большей к меньшей
max2 = -1;
}
// Обе подветки ожидания выключения работают от одной паузы, фиксируем время тут:
curTime = millis();
// Ветка 5 "прошла пауза?"
if( curTime - startedPause >= WAIT_PAUSE )
{
// подветка 5.1 "Выключение ламп датчика1"
if(
(isGo1 == -1)
){
// Подветка 5.1.1 "Текущая лампа УЖЕ выключена?"
if( fades[lamp1].bright == 0 ){
lamp1++; // "ДА" переходим к следующей (к большей!):
}else{
fadeLED(lamp1, isGo1); // уменьшаем яркость на isGo1 каждые WAIT_1 мсек:
}
}
// Ветка 5.2 "Выключение ламп датчика2"
if(
(isGo2 == -1)
){
// Подветка 5.2.1 "Текущая лампа УЖЕ выключена?"
if( fades[lamp2].bright == 0 ){
lamp2--; // "ДА" переходим к следующей (к меньшей!):
}else{
fadeLED(lamp2, isGo2); // уменьшаем яркость на isGo2 каждые WAIT_1 мсек:
}
}
// Подветка 5.3 "Все лампы датчика1 выключены?"
if( isGo1 == -1 && lamp1 == max1 ){
isGo1 = 0; // .. ну и ладушки, всё погасло
}
// Подветка 5.4 "Все лампы датчика2 выключены?"
if( isGo2 == -1 && lamp2 == max2 ){
isGo2 = 0; // .. ну и ладушки, всё погасло.
}
} // конец ветки сработавшей паузы
То, что я вам написал сразу (теперь вижу, что поторопился), просто есть "оптимизация" этой ДРАКОН-схемы. Можете обнаружить что значительная часть исполнения или повторяется почти одинаково или является дополнением else. Рекомендую сравнить тот код, который у вас работал с одним датчиком и эту ДРАКОН-схему и самостоятельно найти КАК происходили преобразования.
Ну и тут видна уже "засада" (вот он ДРАКОН!), а именно: Пауза задержки изменения яркости WAIT_1 считается в одном месте, а икон "Вставка" - 4шт! Соответственно, при одновременном попадании в ветки по isGo1 И isGo2 .. эта пауза будет срабатывать "не так как хотелось". Для каждого датчика надо иметь свою паузу. Это можно решить, если проверку паузы вынести изнутри fadeLED() в вызывающий код "обратно", оставив внутри функции только само изменение .. но можно пойти иным путем .. :)
Разбирайтесь пока с предыдущей программой, в части КАК были выполнены преобразования и свернута ДРАКОН-схема для 1 датчика.
1. При одновременном включении двух датчиков, не происходит включения с обоих краев! Сразу включается 1 и 6 лампы, как и хотел, но потом включение идет от 1 к 6 лампе!
2.В этом же моменьте, заметно моргание 6 лампы! (как будто она переберает весь массив на себе только)
Ну и, давайте побеждать, в смысле осваивать алгоритмирование дальше. В этом плане, скетч конечно же НЕ рабочий ..
По сути (я уже писал раньше) он представляет из себя 2 конечных автомата, каждый из которых перебирает состояния от своего датчика. Давайте реорганизуем сктеч так, чтобы состояния автоматов (ветки) шли не в перемежку, а последовательно: сначала всё что делает первый КА, а потом только второй. Публикуйте.
1. У вас сейчас есть несколько иной алгоритм для loop() с развернутыми условиями .. хде он? Вот, опубликуйте ту версию скетча, где использована развернутая ДРАКОН-схема и в которой ветки сгруппированы последовательно: сначала всё для первого датчика, а потом для второго.
2. После того, как Вы помучались с неверно определенным параметром, я ожидал, что Вы впечатлитесь сложностью проблемы розыска такого рода ошибок и САМОСТОЯТЕЛЬНО прошерстите весь оставшийся код на предмет соответствия типов данных и диапазонов значений .. этого НЕ произошло. Вам хочется ещё раз повылавливать трудно обнаружимые ошибки типов данных, неверно работающих условий, утечек памяти и т.д.? :) Их там было ещё оставлено сознательно .. найдите.
А потом продолжим. Эта ДРАКОН-схема не совсем "рабочая" .. ожидать что код "заработает как надо" - пока не стоит. Это этап вашего обучения.
когда срабатывает датчик(лампы уже горят) то так
Кнопка "изменить пост" - и удаляете портянку.
Да. Обратите внимание что яркость 255 и НЕ уменьшается вовсе..
Кнопка "изменить пост" - и удаляете портянку.
Да. Обратите внимание что яркость 255 и НЕ уменьшается вовсе..
удалил!
Да заметил!
мозголомы...
Как то мягко сказано)))))))))
А тем не менее, функция вызывается, и декремент лампы 2 у ней в параметрах есть. Как понимаю проблема тут:
void fadeLED(uint8_t lamp, uint8_t state)
поправьте на int8_t или просто char (он знаковый). И зацените важность верного указания типа данных и его диапазона значений. :)
Заработало?
Почему теперь вместо 255 так?
Заработало?
Ага!:)
Вот теперь срабатывает мгновенно!
Ага.
На самом деле, это самая ТИПИЧНАЯ ошибка в языках С/С++. Тип целочисленных значений и диапазон значений надо ВСЕГДА проверять в первую очередь.
Подведем итоги:
1. Сначала построение правильного алгоритма.
2. Оптимизация алгоритма. Да, да прямо вот в ДРАКОН-схеме. :)
3. Кодирование. Оно после п1.п.2 как правило "вопросов" не вызывает и делается "левой задней пяткой" при определенном навыке.
4. Отладка. Опечатки и пр. никто не отменял. Равно как и забывчивость, напрожатие клавиш на клавиатуре и т.д.
Ну и далее. Добавить в этот код второй датчик, я думаю Вы уже сможете самостоятельно. Да, и помните, что "пауза" у них одна. :)
На и там есть "засада": взаимное влияние процессов включения/выключения ..
Можете выдать побольше кусок с :f: 2004 .. так оно писать "не может" .. там нельзя выдать болье 255 (в переменную не влезет), и прилепленное число из fadeLED() должно отличаться ровно на 1 в ту или иную сторону..
#define WAIT_1 1 здесь скорость увеличения-уменьшения яркости?
Можете выдать побольше кусок с :f: 2004 .. так оно писать "не может" .. там нельзя выдать болье 255 (в переменную не влезет), и прилепленное число из fadeLED() должно отличаться ровно на 1 в ту или иную сторону..
все разобрался! это я накосячил!
Голова уже не квадратная, кубик рубик уже!)))))
Добавил остальные пины на лампы, все отлично работает, пока с одним датчиком! Только вот одна загвоздка, уж очень долго они ВСЕ загораются( не ШИМ, а пауза между лампами) все 6 ламп загораються за 1мин 32сек, долговато! Можно уменьшить? Менял время шим, они просто быстрее загораются, но весь процесс с тем же временем!
Вчера отвлекли.
1. Да, #define WAIT_1 -- это время паузы между двумя изменениями ШИМ. Если слишком долго, то можно увеличить "шаг" изменений isGo, но тогда его проще выбирать кратным диапазону 0..255. И все сравнения isGo1 == 1/-1 надо будет поменять на величину шага. Проще и правильней завести константу STEP_1 и заменить на неё все +1 и -1 (isGo1 == STEP_1, isGo1 == -STEP_1).
2. Каждая последующая лампа зажигается только после включения предыдущей, что приводит к длительному суммарному времени поджига при больших задержках шага и мелком шаге. Там нет никакой "паузы между лампами". Общее время включения не может быть "одним и тем же".
Играйтесь, подбирайте то, что вам подходит больше всего. Обратите внимание на нелинейность яркости ламп от ШИМ. Видимые изменения яркости ощущаются вовсе не на всем диапазоне 0..255. Может правильнее дополнительно в цикле включения лампы сразу устанавливать начальное значение не в 0, а побольше. Тоже - подбирать только опытным путем, методом "научного тыка". Зависит от типа ламп тоже.
3. Писал, нет? В целях отладки, отключите датчик от платы и сделайте его эмуляцию в программе. Заодно можно закорментарить и его часть setup(). Эмуляция делается просто: заводите статическую переменную uint8_t pirOn=1; перед loop(); в условии проверки комментируете вызов датчика /* */ и вместо него втыкаете pirOn==1. И добавляете внутрь блока команду сброса переменной pirOn=0; все. При первом заходе в loop() проверка "сработал датчик?" даст ответ "да" и сбросит его значение. При последующих заходах - псевдодатчик уже не сработает и Вы можете наслаждаться незамутненным выводом диагностики.
для ускорения включения надо диапазон 0..255 приращивать не на единичку, а на 4 или 8.
вот в этом диапазоне реальное изменение свечения, видимое глазу!
для ускорения включения надо диапазон 0..255 приращивать не на единичку, а на 4 или 8.
это я уж вкурил, но тут не в этом дело, мне кажется!
Вернемся в начало, пост №1 скетч от туда, общее время включения 3 ламп = 6 сек
Сейчас время включения первых 3 ламп = 39 сек
Разница очевидна! ШИМ везде одинаков = +1 каждые 10мсек - пауза между изменениями яркости!
Вопрос; почему???
Полагаю из-за вывода диагностики в сериал. Прикройте вывод диагностки и сравните, она - очень не шустрая.
Полагаю из-за вывода диагностики в сериал. Прикройте вывод диагностки и сравните, она - очень не шустрая.
прям в точку!!!
Вы бы выложили окончательный скетч для всеобщего пользования. Платформа Ардуино, всеж-таки предполагает открытую разработку. Вдруг кому ещё пригодится..
я выложу, и видео и все где был и делал! Вдруг кто то не только захочет просто залить скетч, а и понять как он делается и устроен! Ну как я типо!))) Правда я пока еще не особо понял, но... Москва не сразу строилась!
Вот построение алгаритма, весьма не плохо понял! Хорошая книга!
И я еще не делал со вторым датчиком, может там какие-то неувязки будут!
Конечно будут, просто обязательно! Вы же .. учитесь. :)
1 момент: список ламп у вас как был один, так и должен остаться .. но управляться он будет уже из двух ветвей силуэта.
2. Пазуа на выключение .. одна. И точка её старта во времени должна переопределятся ОБОИМИ ветвями (датчиками) заново.
3. Функция fadeLED потребует упрощения. Сейчас она считает текущую задержку для текущей лампы и такая пока .. ОДНА. Как только добавите второй датчик, потребуется считать .. ДВЕ задержки, на каждую из включаемых датчиками ламп (они могут включаться и не синхронно вовсе: 1-й уже догнал до 120, а второй "только начал" включать свою лампу).
4. Попытки включать/выключать одну и ту же лампу (скажем среднюю) двумя алгоритмами .. надо "подсматривать" за текущим индексом второго алгоритма .. дабы не пересечься.
5. Первый датчик выключал .. и тут второй решил пора включать .. остановить бы первый .. :)
В общем, как вижу ничего особо сложного нет, но есть смысл разрисовать ДРАКОН схему и проверить движение сквозь ВСЕ ветки вариаций дотошно. Устранить полностью все коллизии вам все одно не удастся, ибо датчиков только 2, но привести к вполне разумному поведению - можно. :)
ВСЁ уже паника!
Для меня камни уже тут начались)))
Не могу понять что надо поменять, чтоб не в обратном порядке выключались, а в том же что включались!?
Ну .. когда лампы включаются, задается lamp1 = 0, max1 = MAX_LED, так? И далее по коду есть проверка с инкрементом номера лампы lamp1++. И это приводит к тому что начинаем включать с лампы номер 0 (массив с С - всегда начинается с нулевого индекса) и заканчиваем номером MAX_LED-1 (предыдущим от max1) ..
Соответственно, "в обратном" порядке счетчик номера ламп lamp1 надо сразу поставить в последний номер - то бишь "предыдущий" от MAX_LED и последним выключаемым номером будет 0, а стало быть "следующим" будет -1.
Тоесть, если хотим "в том же" порядке, то и надо установить стартовые значение в "тот же порядок" и вместо декремента lamp1-- написать инкремент lamp1++
А где такое в коде есть? Я что то не вижу!:(
А, все, опять туплю))))
Вот она)
Вот тут чуть разжувал, ну чтоб мне понятнее было! Правильно?
Даа, чую самому мне пока не разобраться!:(
Верно всё поняли. В этом месте задается прямой порядок обхода ламп. Всё у Вас получается, просто не стоит торопится. :)
значит для того чтоб запустить лампы в другом порядке от этого же датчика надо так что ли?
но не верно понимаю)
ни как не выходит включить в другую сторону)
Почему lamp1 = MAX_LED? MAX_LED ваще-то равно трем, ибо ТРИ лампы .. но нумеруются они с 0 по 2 .. то есть, если хотите включать в порядке 2,1,0 .. надо присваивать MAX_LED-1, нет? :) А проверять до какого значения? :)
А почему трем, если вроде шести должно?
Опять же если я правильно понял!
Ну вот здесь я понимаю так
Так?
Ну пусть будет 6 .. пофиг. Номера элементов массива все равно идут с ноля и до количества элеметнов БЕЗ 1. То есть 0,1,2,3,4,5 (5 = 6-1 = MAX_LED-1)
А проверять до какого значения? :)
я так думаю до 5,но почему- то терзают смутные сомненья!)
работает:)
Не-а, не должно работать, если MAX_LED = 6. :)
Точнее 1 раз оно сработает, поскольку сначала делаем действие с лампой (включаем/выключаем, но я бы хотел посмотреть на тот скетч, с которым Вы сейчас пробуете), если её яркость ещё не достигла предела, а только потом проверяем границу индекса .. и вот тут у вас произойдет "завершение" этого размазанного цикла, ибо lamp1 = MAX_LED-1 = 6-1 = 5 = max1.
Если Вы начинаете с последнего элемента "5", то закончить перебор ламп надо первым элементом с номером "0". А поскольку этот цикл организован по принципу do{}while() (покраска забора), то он сначала исполняет действие с текущим значением счетчика и только потом изменяет его для следующей итерации с проверкой на завершение. Смотрите:
lamp1 = 5 -- устанавливаем ДО начала do{}while(). Далее исполняем тело цикла и изменяем значение на "следующий номер" .. lamp-- .. =4, после чего проверяем .. и повторяем цикл. Получается: 4, это всё? нет: 3, это всё? нет: 2, это всё? нет: 1, это всё?, нет: 0, это всё? ... НЕТ! нам надо ещё вернуться в начало цикла и обработать нулевой элемент массива .. но в конце стоит lamp-- и оно примет значение .. -1. А вот теперь -1, это всё? ДА.
Так чему должно равняться max1, если у нас стоит проверка lamp1 == max1? :)
Пока прочитал, уже удалил скетч( Да, начались глюки, то 2 горят, то мигают все и т.д
Переделал так
Работает! :) Вот только какая то задержка, между 1 и 2 лампами(все сериалы прикрыл) что может это быть? А так все четко, как в ТЗ)
Вникаю в эту задержку и во второй датчик)))
Попытка объеденить два рабочих скетча, неудача:)
Похоже я сильно поторопился, объединив в одной проверке несколько разных условий ДРАКОН-схемы. Давайте вернемся чут-чуть назад к ДРАКОН-схеме:
То, что я вам написал сразу (теперь вижу, что поторопился), просто есть "оптимизация" этой ДРАКОН-схемы. Можете обнаружить что значительная часть исполнения или повторяется почти одинаково или является дополнением else. Рекомендую сравнить тот код, который у вас работал с одним датчиком и эту ДРАКОН-схему и самостоятельно найти КАК происходили преобразования.
Ну и тут видна уже "засада" (вот он ДРАКОН!), а именно: Пауза задержки изменения яркости WAIT_1 считается в одном месте, а икон "Вставка" - 4шт! Соответственно, при одновременном попадании в ветки по isGo1 И isGo2 .. эта пауза будет срабатывать "не так как хотелось". Для каждого датчика надо иметь свою паузу. Это можно решить, если проверку паузы вынести изнутри fadeLED() в вызывающий код "обратно", оставив внутри функции только само изменение .. но можно пойти иным путем .. :)
Разбирайтесь пока с предыдущей программой, в части КАК были выполнены преобразования и свернута ДРАКОН-схема для 1 датчика.
Скетч рабочий! Пока вижу две проблемы!
1. При одновременном включении двух датчиков, не происходит включения с обоих краев! Сразу включается 1 и 6 лампы, как и хотел, но потом включение идет от 1 к 6 лампе!
2.В этом же моменьте, заметно моргание 6 лампы! (как будто она переберает весь массив на себе только)
Кстати, всех с Праздником Победы!!!
Спасибо, и Вас тоже с праздником Победы!
Ну и, давайте побеждать, в смысле осваивать алгоритмирование дальше. В этом плане, скетч конечно же НЕ рабочий ..
По сути (я уже писал раньше) он представляет из себя 2 конечных автомата, каждый из которых перебирает состояния от своего датчика. Давайте реорганизуем сктеч так, чтобы состояния автоматов (ветки) шли не в перемежку, а последовательно: сначала всё что делает первый КА, а потом только второй. Публикуйте.
Ну это получается что ветка второго датчика должна начинаться после
Я правильно понял?
Пробуйте уже! Стоит меньше опасаться совершить ошибку. "Человеку свойственно ошибаться". (с) давно-давно.
Веселее пошло! Тестирую....:)
Все четко пока! Одна проблема, вот эта пауза между включением 1 и 2 лампы и 6 и 5(секунды 2-3 задержка примерно)!
Всю картину портит!
Стоп. ТАК учиться мы НЕ будем.
1. У вас сейчас есть несколько иной алгоритм для loop() с развернутыми условиями .. хде он? Вот, опубликуйте ту версию скетча, где использована развернутая ДРАКОН-схема и в которой ветки сгруппированы последовательно: сначала всё для первого датчика, а потом для второго.
2. После того, как Вы помучались с неверно определенным параметром, я ожидал, что Вы впечатлитесь сложностью проблемы розыска такого рода ошибок и САМОСТОЯТЕЛЬНО прошерстите весь оставшийся код на предмет соответствия типов данных и диапазонов значений .. этого НЕ произошло. Вам хочется ещё раз повылавливать трудно обнаружимые ошибки типов данных, неверно работающих условий, утечек памяти и т.д.? :) Их там было ещё оставлено сознательно .. найдите.
А потом продолжим. Эта ДРАКОН-схема не совсем "рабочая" .. ожидать что код "заработает как надо" - пока не стоит. Это этап вашего обучения.
Стоп. ТАК учиться мы НЕ будем.
1. У вас сейчас есть несколько иной алгоритм для loop() с развернутыми условиями .. хде он?
Ну ок! Тогда разжовывайте что это значит! Для меня это пока не понятно!
Две разных ветки, я вижу! вроде понял как они стоят в программе и ей определяются!
А вот слово "развернутыми" настораживает! :)