[Sybastian]

Как вариант хостинга – https://bitbucket.org
У них вроде бы нет ограничений на кол-во публичных/закрытых репозитариев и пользователей.

[Sybastian]

Счастливчик писал(а):

Как вообще ветвится дерево разработки…

Единого стандарта не существует, инструмент позволяет вносить изменения в в любую ветку разработки, сливать/объединять ветки, и при обнаружении конфликтов – разруливать их.

К примеру, если рассматривать вариант ОДНОЙ актуальной версии ПО, то дерево может быть таким:
– master (основная/актуальная и стабильная версия)
– dev (отладочная ветка)
…
– dev/feature_123 (отладочная ветка ф-ции 123)
– dev/feature_N (отладочная ветка ф-ции N)

Счастливчик писал(а):

как им управлять, как сливать бранчи…

Если в контексте примера выше, на начальном этапе создается репозитарий (ветка master создается автоматически) и если есть – заливается стабильная версия. Далее создаем ветку dev, наследуя от master, все правки и изменения будут переноситься в master путем слияния именно с веткой dev. Когда необходимо что-то изменить, то все правки вносим в dev, или создаем отдельную ветку которую наследуем от dev, тестируем и если все “Ок” обратным слиянием (т.е. feature_123 -> dev -> master) релизим версию. Инструментарий поддерживает различные метки/комментарии, т.е. при желании не запутаешься. При разработке в под-ветках важно не забывать синхронизировать свою под-ветку с исходной (к примеру dev) перед внесением очередных изменений, чтобы избегать трудоемкого процесса устранения конфликтов при слиянии.

Если реализовывать структуру “отдельная версия – отдельное дерево”, то просто таких деревьев (master/dev/…) придется создать по кол-ву версий.

И да, во избежание недоразумений, master веткой управляется кто-то один, остальные участники процесса не должны иметь прав на запись в эту ветку.

[Sybastian]

Счастливчик писал(а):

Sybastian писал(а):

в котором как минимум dallRead(flagDallRead*1000) является блокирующей (в среднем от 200 до 750 млс * кол-во датчиков)

Неправильно. Чтение датчиков асинхронное. Сначала идет запрос на измерение температуры, затем опрос датчиков. Все это напрямую по счетчику millis. Т.е. задержек нет вообще.

Верно, не обратил внимания что чтения датчиков происходит только OneWire(в моей реализации еще есть DallasTemperature, которая и устраивает 0,7сек. задержку на датчик)

 

[Sybastian]

В Heater.ino, ф-цию heaterLoop() можно упростить, к примеру так:
void heaterLoop() {
if ( heaterStatus ) {
ResOut();
State = !State;
lastTime = millis();
}
else { digitalWrite(heater, 0); }
}

В частности:
– строка/блок “if ( lastTime + 250 <= millis() )…” не нужна, т.к. “lastTime + 250” всегда будет меньше millis() из-за вызова heaterLoop() из основного цикла программы, в котором как минимум  dallRead(flagDallRead*1000) является блокирующей (в среднем от 200 до 750 млс * кол-во датчиков)
– оптимизация/упрощение

[Sybastian]

Исходя из листинга, реальный контроль “нуля” никак не осуществляется (да и не требуется в данной реализации), семистор сам закроется когда “увидит 0” и программе останется только окрыть его (согласно настроек)

[Sybastian]

Кожухотрубник(500мм) на 7 трубок 12мм справляется с 3кВт., расход воды прим. 50-60 л./ч.

[Sybastian]

Поддержу вариант “аквариумная помпа/насос” – в мощности 150-200 Вт. легко перекачивает на 1-1,5м по высоте.

[Sybastian]

Смотря о чем идет речь, если РК – то в “узле отбора” не актуально, в 1/3 (сверху) насадочной части более оправдано, если речь о БК(пленочной) и под “узлом отбора” подразумевается точка-переход в конденсор – актуально, ибо по другому не получиться контролировать эффективную работу БК.

[Sybastian]

Сутками углевать не стоит, для сравнения использовал: одинаковые навески угля(кокосовый, фракция 2-3мм., навеска 3гр./л.,промыт и прокипячен 3-5 мин.), 4л. СС 45-50%, темп. 19-20С; Вариант №1 –  усиленно помешивал(частицы слишком “тяжелые”, быстро тонут) в течении 20-30 минут, Вариант №2 – размешал и оставил на прим. 20 часов. На выходе – пахнут одинаково, на вкус Вариант №2 чуть жестче/резче(субъективно).

Вложения:

Вы должны войти для просмотра вложений.

[Sybastian]

После нескольких опытов остановил выбор на CATSAN Ultra: при стабильности и схожести результатов у него меньшие потери(по браге); нужно или нет – вопрос философский, для зерновых(при погоне на ТЭН-ах) очень помогает, но “потери”…
Особой разницы в запахе и вкусе продукта не ощущается(при двойной перегонке)

Технология использования:
– перемолоть всю навеску бентонита (1 столовая ложка на 10 литров браги) в кофемолке/миксере до фракции “пыль”; (за кофемолку не переживай – чистится легко)
– добавить горячую воду (0,5 литра на 1 столовую ложку помола бентонита), затем перемешать миксером или ложкой до образования однородной массы; настаивать 12-20 часов;
– тонкой струей влить раствор бентонита в брагу, перемешать (лучше строительным миксером) и оставить на 1-1,5 суток при комнатной температуре;
– слить с осадка;

 

Вложения:

Вы должны войти для просмотра вложений.

[Sybastian]

Да так и делаю, разве что вместо солода – ферменты.
Но повторяемость положительного результата никакая – через раз йодная проба “фиолетовый/красный”, т.е. не весь крахмал превратился в мальтозу и декстрины (осахаривание не закончено) – отсюда сомнения: не разварилось как следует или ферменты дохлые? Грешу все же на разваривание…

[Sybastian]

Приветствую, коллеги.

Вопрос (к Счастливчику) – узел отбора по пару расположен ниже узла отбора по жидкости, умышленно (к примеру, чтобы иметь зазор по высоте для врезки в до-охладитель)? На что влияет взаимная диспозиция узлов?

[Sybastian]

Спиртуозность 95% в “погоне”, или на старте(в “головах”)?

[Автор]

Сообщения