eu_tomat

17 минут назад, BrightYC сказал:

Надеюсь, ты не против, если я кину сразу видео?
https://youtu.be/wOBoQ2WoAQw
Можно заменить ультразвуковой датчик на дальномер, думаю принцип не будет сильно отличаться. 

В видео я не услышал главного: почему после поворота на один градус нужно ждать именно 30 миллисекунд. Почему не больше? Почему не меньше? Изменится ли эта задержка при повышении или понижении напряжения питания сервопривода?

14 минуты назад, BrightYC сказал:

Здесь уже помогут моторчики как в жёстких дисках или 3д принтерах. Они называются "шаговые двигатели". Их положение можно определить со 100% точностью, поэтому для этого они идеально подходят. Но это не совсем обычные двигатели - им нужен специальный драйвер. Что опять же усложнит конструкцию и порог входа.

Насколько я знаю, положение шагового двигателя со 100% точностью мы можем определить лишь в одном случае: если знаем его начальное положение. Ну, и если не было пропуска шага при работе двигателя с перегрузкой. Перегрузки у нас не будет. Но как определить начальный угол вала шагового двигателя при включении робота?

@BrightYC Спасибо за разъяснения. Это поможет мне быстрее вникнуть в предмет. Я погуглил тему датчиков, и там всё оказалось сложно.

Дешёвые датчики имеют малую дальность. То есть, роботу будет нельзя сильно разгонятся.

Дорогие датчики по сути являются дальномерами. Они видят сравнительно далеко и точно, и точность, как это ни странно, создаёт новые проблемы: препятствие может оказаться между лучей, и робот его не заметит. Чтобы заметить препятствия между лучами, робот должен крутить головой. И желательно, крутить головой достаточно быстро. И тут начинается самое интересное.

Правильно ли я понимаю, что сервоприводы для Ардуино могут лишь воспринимать управляющий сигнал без возможности передать контроллеру фактический угол поворота? И если сервоприводу дать команду развернуться в крайней положение из противоположного, то время завершения операции можно определить лишь примерно? Оно, насколько я понимаю, зависит от питающего напряжения? И является ли скорость поворота сервопривода более-менее постоянной, или сервопривод замедляется ближе к целевой точке? И есть ли у сервопривода крайние положения? Может ли он непрерывно вращаться на 360 градусов?

Зная ответы на эти вопросы, можно было бы вращать головой на полной скорости сервопривода, считывая расстояния до всех предметов на горизонте.

Ещё есть идея вскрыть сервопривод, и если позволит схема, подключиться непосредственно к потенциометру сервопривода. Это позволит точно определять угол даже не остановившегося сервопривода.

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

Здравствуйте, товарищи!

Я в очередной раз заинтересовался темой микроконтроллеров и на этот раз я намерен перевести свой интерес в практическую плоскость. При выборе платформы я склонялся сначала к Arduino, но потом вспомнил о платформе NodeMCU, с которой нас познакомил @BrightYC. NodeMCU позволяет писать программы на языке Lua, благодаря чему эта тема может стать интересной более широкому кругу форумчан. Поэтому для первого проекта я выбрал NodeMCU.

Должен сразу сказать, что тему микроконтроллеров я знаю поверхностно и лишь теоретически. И я слабо представляю возможности типовой периферии Arduino и NodeMCU, и насколько совместима эта периферия между платформами. Поэтому я буду рад любым советам.

Ближайшая цель: выбрать комплектующие для проекта и заказать их в Китае. Можно заказать и в России, если это будет не сильно дороже.

Конечная цель проекта:
Минимум:

• Сделать игрушечную машинку на четырёх колёсах с танковым разворотом, способную случайно блуждать по полу, объезжая препятствия. Датчики препятствий нужны какие-то оптические, чтобы не пугать ультразвуком котов. Датчики желательно аналогвые, чтобы знать примерное расстояние до препятствий, если это вообще возможно на типовых модулях. Также требуется подключение по WiFi для отладки скриптов.
• Датчиков препятствий пока планируется три: один смотрит вперёд, а другие немного в стороны, чтобы выбрать предпочитительное направление для поворота, не вращая корпус машины.
• Машинка будет иметь четыре колеса с двигателями и редукторами на каждое колесо. Колёса требуются какие-нибудь простые и недорогие. Двигатели будут объединены в две группы, для их управления нужен какой-нибудь модуль драйвера. Драйверы будут управляться либо аналоговым сигналом, либо ШИМ, чтобы машинка могла двигаться с переменной скоростью и делать повороты различного радиуса.
• Также требуется аккумулятор для питания устройства и контроллер заряда с USB-интерфейсом.

Опционально:

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

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

Вопросы на текущем этапе:

• Как выбирать плату контроллера? Установлен ли на плату WiFi, или он устанавливается отдельным модулем?
• Насколько часты у начинающих самодельщиков случаи "ткнул не туда, плата сгорела"? Имеет ли смысл взять несколько плат на всякий случай?
• Какие выбрать модули для управления двигателями? По каким критериям?
• Какие существуют оптические датчики расстояния? Могут ли они выдавать аналоговый сигнал, и есть ли в аналоговом сигнале какой-либо смысл?
• Как выбрать аккумулятор и контроллер заряда?
• Как подключаются сервомашинки к контроллеру? Нужны ли им дополнительные модули драйверов?
• Какая периферия требуется для воспроизведения звуков с флешки?

Если какие-то из моих формулировок вам непонятны, задавайте уточняющие вопросы. Я пока сам не знаю, как правильно сформулировать свои мысли в новой для меня теме. На практике я знаю лишь Lua, да умею пользоваться паяльником, а также знаю основы электроники и электротехники. А вот, всякие там Ардуинки и прочие конструкторы в руках держать пока не доводилось, и возможностей компонентов я тоже не знаю. Надеюсь обо всём этом узнать в процессе реализации данного проекта. Возможно, с вашей помощью.

14 часа назад, BrightYC сказал:

1. Открыл тему на википедии по ядерным реакторам

2. Бегло посмотрел на кол-во текста

3. Закрыл вкладку и пошёл плакать в подушку

Чтение является основным занятием программиста: читать код, читать спецификации, читать задание. Не всегда их текст короток и, что ещё хуже, не всегда соответствует друг другу. И лишь во вторую очередь программист пишет текст: код, спецификации. задание.

Есть две ссылки: для урана и для MOX:

Цитата

Урановый ТВЭЛ работает 20000 секунд (до экспериментальной версии было 10000 секунд), постепенно теряя прочность. В конце работы он превращается в обеднённый урановый ТВЭЛ (до экспериментальной версии с шансом 25 % превращался в обеднённый ТВЭЛ, или же исчезал).

 

Топливный стержень (MOX) работает 10000 секунд постепенно теряя прочность. В конце работы он превращается в Обеднённый MOX ТВЭЛ. В отличие от урановых стержней при нагреве реактора эффективность МОХ увеличивается.

Но фокус, как всегда, в том, что эта информация не совсем верна. И для её уточнения, не всегда требуется читать много текста или писать код. Предлагаю провести следующие эксперименты:

• Пространство реактора с шестью дополнительными камерами заполняем теплоёмкими реакторными обшивочными пластинами, а в один из слотов помещаем одиночный урановый ТВЭЛ. К реактору подключаем MFSU. На реактор подаём сигнал редстоуна и уходим гулять. Часов через пять с половиной убеждаемся в том, что стержень сгорел до конца, проверяем энергию в MFSU, а также нагрев реактора. Для проверки нагрева можно воспользоваться компьютером или информационной панелью из NuclearControl. Зная расчётный выход энергии и тепла, можно оценить фактическое время работы реактора.
• Эксперимент аналогичен предыдущему. Но вместо урана используется MOX. Проверяется нагрев реактора. На эксперимент уходит около трёх часов.
• Ещё один эксперимент с MOX. Но вплотную к стержню кладётся разогнанный теплоотвод. Проверяется энергия в MFSU.

Эксперименты с MOX можно объединить в один, но тогда для проверки выделенной энергии придётся заняться интегрированием и потом искать ошибку, либо в своём интегрирующем коде, либо в реализации ic2exp, это занятие лишь для самых суровых программистов.

Все три эксперимента не запрещается провести параллельно и даже воспользоваться модами, повышающими TPS и ускоряющими течение времени в Майнкрафте, насколько позволяют ресурсы компьютера.

После получения экспериментальных данных о фактическом выходе тепла и энергии при работе стержней можно задуматься о дальнейших экспериментах.

А сколько вам удалось выжать тепла и энергии из одиночно стоящих стержней из урана и MOX?

1 час назад, Asior сказал:

разраб утверждает что так и задумано

...

игроки смирились и придумали схемы автозапуска на импульсе по редстоун сигналу

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

А роботы тоже отключаются? Потому что в этом случае самых простых роботов-шахтёров после перезагрузки сервера искать придётся вручную.

4 минуты назад, whiskas сказал:

Да другим игрокам, сам багу не уточнял, мне говорила администрация. Но я подозреваю что єто делают пакетами данных.

Что за пакеты такие? Это же не сетевые пакеты? И, может быть, это не бага, а фича тех серверов?

26 минут назад, BrightYC сказал:

Я тоже такое не везде замечал.

Вот, я и думаю: это результат взаимодействия модов в сборке, или владельцы серверов пропатчили мод под свои цели?

3 минуты назад, kaka888 сказал:

Ахах 

Да не нужен мне твой приват. Мне нужен комп на проблемном сервере. А тратить время на развитие ради возможности посмотреть на проблему я в ближайшее время не планирую.

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

7 минут назад, BrightYC сказал:

Был такой баг на 2 серверах где я играл. На одном из них разработчик сумел это пофиксить - но детали я не знаю. Да, игрок действительно не влияет на выключение компьютера. При длительном выгрузе чанка компьютер просто выключается. Всё

На наших сборка такого вроде бы не было. Помню, мониторы от gpu отцеплялись, и эта проблема была пофикшена. Но компы OC вроде не вырубались.

8 минут назад, whiskas сказал:

Как я помню что появилась какаято бага через какую можна офать комп игрокам

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

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

49 минут назад, kaka888 сказал:

Сервер на версии 1.7.10. Постоянно вырубается комп с включённой консолью или с работающей прогой, если чанк долго не прогружается. Сразу говорю - не из-за энергии.

Комп полностью выключается, или только пропадает картинка на мониторе? Какая версия OpenComputers?

Вопрос разработчикам модов Майнкарфта.

Попытка понять странности поведения одного мода привела меня к чтению его исходного кода, полученного с помощью декомплятора. И там я встретил кучу непонятных методов со странными названиями. Я впервые вижу написанный на Java код, и, возможно, могу что-то понимать неправильно. Кроме того, я совершенно не знаю, как пишутся моды для Майнкрафта. Поэтому я не уверен даже в постановке вопроса.

Код Майнкрафта, скорее всего, обфусцирован, и поэтому названия методов имеют нечеловеческие названия. Для создателей модов наверняка существуют какие-то справочники, но поиск пока привёл меня лишь к исходным текстам каких-то модов.

Вопросы:

• Что делает метод net.minecraft.item.ItemStack.func_77964_b?
• Что это за API, и API ли это?
• Майнкрафтовский ли это API, или ещё чей?
• И вообще, куда копать, чтобы понять эту петрушку?

Вот, мы говорим про микроконтроль. Пытаемся малыми действиями достичь большого эффекта. Но это не значит, что каждую секунду обязательно следует опрашивать какие-то датчики и что-то перемещать. Ядерный реактор Industrial Craft это не самолёт, которому надо учитывать случайные воздушные потоки и турбулентности. Многие процессы в этих реакторах предсказуемы. Зачем прямо сейчас переносить в холодное место один из теплоотводов, если перегрев грозит ему лишь через минуту? Зачем каждый тик проверять догорающие ТВЭЛ'ы, если время их работы точно известно?

Предлагаю несколько похожих загадок:

Есть почти сгоревший урановый ТВЭЛ с разрушением 9980. На сколько секунд горения его хватит? А на сколько хватит свежего уранового ТВЭЛ? А сколько секунд будет гореть сдвоенный ТВЭЛ? А счетверённый?

Теперь то же самое с ТВЭЛ'ами из смеси оксидов. Есть одиночный MOX-ТВЭЛ с разрушением 9980. Сколько секунд сможет гореть он? И сколько секунд будет гореть свежий ТВЭЛ? А сдвоенный? А счетверённый?

У кого какие ответы?

12 минуты назад, Doob сказал:

Не понял, откуда 27 МОХ.

Речь шла об этой схеме:

В 08.10.2019 в 15:37, Doob сказал:

Я тут накидал сбалансированную по всем параметрам схему, дающую 8099 еутиков, погоняю и покажу, может есть еще что дооптимизировать.

Я тут вижу только вариант с 27 MOX. А у тебя какой был?

P.S.: Схема с конденсаторами, ясное дело, не требует дополнительных реакторов для охлаждения.

1 час назад, Doob сказал:

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

Да, конденсаторы сильно упрощают схему охлаждения. Она не требует балансировки.

Но как ты добился лишь одного холодильника при использовании теплообменников? Попробуем посчитать. К слову, я тоже ошибся в своих расчётах. Теперь попробую посчитать правильно.

На уране 8099 eu/t не достичь, даже если забить ТВЭЛ'ами все слоты реактора. Остаётся MOX. Максимальный множитель эффективности для разогретого реактора 4.9996, а для минимизации тепла при максимизации температуры мы используем счетверённые ТВЭЛ'ы с базовой генерацией 60 eu/t. Значит, используется 8099/4.9996/60 = 27 счетверённых стержней MOX. Реактор имеет 54 слота, значит, стержни можно разместить лишь в шахматном порядке.

Каждая сборка генерирует 96 hu/s, а все сборки 96*27 = 2592 hu/s. В свободные ячейки мы можем разместить теплоотводы или теплообменники.

Самый эффективный теплоотвод даёт охлаждение в 20 hu/s на слот, и для полного охлаждения требуется 2592/20 = 129.6 слотов. В рабочем реакторе есть 27 свободных слотов. Фактически меньше, т.к. для поддержания высокой температуры реактора количество разогнанных теплоотводов в реакторе потребуется уменьшить. Но для грубых расчётов будем считать 27 слотов. Значит, для охлаждения потребуется (129.6-27) / 54 = 1.9 охлаждающих реакторов. Два холодильника в самом лучшем случае. Как у тебя получился один?

2 часа назад, Doob сказал:

Я тут накидал сбалансированную по всем параметрам схему, дающую 8099 еутиков, погоняю и покажу, может есть еще что дооптимизировать.

А почему не говоришь, что для охлаждения схемы требуется 2.667 дополнительных реакторов для охлаждения? Получится уже 2208 eu/t на реактор. И то, эффективно использовать дополнительные реакторы получится лишь при количествах, кратных 11 штукам: 3 генерирующих и 8 охлаждающих.

При этом в рамках одного реактора существует сбалансированная схема на 2099 eu/t, что чуть менее эффективно, на 5% меньше в пересчёте на реактор, но зато не требуется согласования работы одиннадцати реакторов друг с другом.

1 минуту назад, Doob сказал:

Но я ведь делал, повторить могу в любое время, при хорошем пинге.

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

Основная трудность: у меня не получилось выдать такой по времени импульс, который бы гарантированно включил реактор ровно на один реакторный такт. А пока что у меня получаются импульсы, либо иногда включающие реактор на два такта, либо иногда вообще не включающие. Чаще всего реактор включается на один такт, но результат не гарантирован.

Как сформировать импульс, гарантированно включающий реактор на один такт? Без NuclearControl и OpenComputers.

5 минут назад, Vaddam1 сказал:

Верстак 5 на 5 добавлен "самописным" модом, который создаётся и меняется техадмином сервера.

Похоже, тут остаётся лишь воздействовать на автора мода. Ещё вместо роботов можно попробовать использовать автокликеры.

18 часов назад, Vaddam1 сказал:

я играю на одном сервере где есть крафты 5 на 5, для этого используется аналог обычного верстака только с сеткой 5 на 5.

А какой мод добавляет верстак с сеткой 5x5?

Я провёл эксперименты со схемой полуавтоматического разогрева реактора за одну секунду без использования компьютеров.

В первую очередь я хотел автоматизировать изъятие теплоотвода. С этим проблем не возникло. Достаточно было лишь развернуть схему так, чтобы теплоотвод вынимался воронкой первым. Затем надо было вспомнить, что в этом случае теплоотвод начинает работать лишь на втором реакторном тике. Эта часть успешно работает.

Но обнаружилась другая проблема. Каменная кнопка должна выдавать сигнал длительностью 1 секунду. На практике оказалось, что 18-19 тиков. Изредка случаются и значительно меньшие значения. Бывало, что кнопка отжималась через 1 тик. Но чаще всего интервал между нажатием и отжатием составлял 18-19 тиков. Замеры проводились с помощью робота, нажимающего кнопку, и компьютера, фиксирующего изменения сигнала красного камня.

Подозревая, что проблема в кнопке, я дал задачу роботу аккуратно генерировать импульсы длительностью 19 тиков с помощью красной платы. Но регистрирующий компьютер получал 18-19 тиков. Меньшие интервалы не были зафиксированы. Компьютер выполнял роль кнопки заметно лучше самой кнопки.

Но разброс между 18 и 19 тиками всё равно оказался критичным. При 19 тиках сигнала красного камня реактор иногда успевает сделать два реакторных тика. А при 18, бывает, не делает даже одного. Джиттер в тиках красного камня и джиттер в тиках реактора делают схемы без обратной связи непредсказуемыми. Пока что я  я реализовал схему на повторителях, которая выдаёт сигнал длительностью 17-18 тиков независимо от глюков кнопки. Это хотя бы позволяет избежать перегрева реактора.

Предварительные выводы таковы:  без обратной связи с реактором (OpenComputers, NuclearControl) сделать схему, гарантированно нагревающую реактор за одну секунду до 9999 hu, невозможно. Лучший результат, которого мне удалось добиться: выложить схему в реакторе, нажать на кнопку, проверить температуру. Если нагрев не выполнен, вернуть из воронки в реактор вытянутые компоненты и нажать ещё раз.

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

Любимая многими ядерщикам схема на 420 eu/t способна работать исключительно в условиях асимметрии.

Даже поняв основные принципы построения реакторных схем, и научившись самостоятельно проектировать реакторные схемы под свои специфические нужды, именно эту схему я долгое время не мог понять. Охлаждение шести сборок у меня не вызывало вопросов. Но охлаждение седьмой сборки (в схеме она расположена в верхнем левом углу) мне казалось какой-то магией. Улучшить эту схему вряд ли возможно. Она в некотором смысле совершенна.

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

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

В 02.10.2019 в 21:19, ArtHacker сказал:

ну вообще-то пара есть. но правда настолько сырые что рассказывать не буду.

В 02.10.2019 в 21:22, Totoro сказал:

Нужно что-то такое, что можно было бы рассказывать.

В идеале - всем, включая своих внуков.

Ну а завтра спросят дети, навещая нас с утра:
"Папы, что сказали эти кандидаты в доктора?"
Мы ответим нашим чадам правду, им не все равно:
Удивительное рядом, но оно запрещено!

20 минут назад, NEO сказал:

Я пока вижу разницу в нагревании и охлажлении, в первом реактора охлаждает, а потом нагревает, во втором наоборот. Но я далёк от ядерных реакторов так что могу проглядеть деталь.

 

P.S ну как далёк, я один раз почти полностью рабочий планировщик написал.

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

В первой схеме сначала обсчитывается теплоотвод. На первом реакторном тике корпус холодный, поэтому теплоотвод по сути не работает. Потом обсчитывается ТВЭЛ. Он нагревает корпус на 4 hu. На втором тике теплоотвод забирает от корпуса все 4 hu и рассеивает их, а ТВЭЛ снова нагревает. В результате стабильно работающая схема всегда будет поддерживать тепло корпуса реактора на уровне 4 hu.

Во второй схеме сначала обсчитывается ТВЭЛ, он отдаёт на корпус 4 hu, а теплоотвод затем забирает их и рассеивает. Стабильная температура корпуса имеет нулевое значение. Здесь на промежуточной стадии корпус также имеет 4 единицы тепла, но по завершении тика тепла в корпусе нет.

А если ТВЭЛ'ы все вместе выдают 10004 hu/s, а теплоотвод забирает 5 hu/s, то при неудачном расположении теплоотвода реактор превысит критическую температуру на первом же тике.

Вывод: зеркальные копии схем не всегда равноценны оригиналам.

35 минут назад, Doob сказал:

Тут еще надо разобраться как считать. У реакторов, для теплового и энергетического баланса, подходит алгоритм решения задачи на взвешивание.

Да, хорошая иллюстрация одного из способов оптимизации.

Поделюсь ещё одной интересной задачкой для ядерных экстремалов:

Какова температура корпуса реактора у первой и второй схемы, и почему?

Сразу скажу, что температура отличается, хотя тепловой баланс схемы, казалось бы, одинаков: поступает 4 hu/s на корпус, и снимается с корпуса максимум 5 hu/s. В приведённых двух схемах, как и в большинстве других, это различие не оказывает решающего влияния на работу реактора, и это позволяет забыть о проблеме. Но для моего реактора, который должен был нагреться ровно до 9999 градусов, это различие оказалось фатальным.

23 часа назад, eu_tomat сказал:

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

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

3 минуты назад, Doob сказал:

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

Почему же невозможно?

Вот, например, правдоподобная хронология установки реакторов: 115.75, 118.30, 120.60, 126.15 секунд. Если предположить, что инициализация  циклов реактора происходит на том же тике, то в результате такой хронологии во время игровой секунды сначала будет отработан такт четвёртого реактора, затем второго, потом третьего, а за ним первого.

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