Эта статья является прямым продолжением предыдущей публикации на данную тему. К тому же, от пользователя @Sotnya1337 прозвучал вопрос

«Подскажите пожалуйста, угол fi мы выбираем наобум? Было бы интересно рассмотреть автоматическую логику управления, без ручного выбора угла fi »

требующий ответа. Более того — этот ответ я и сам хотел получить довольно давно. Но, как я и писал ранее, в отечественной литературе этот вопрос не освещается вообще, а в зарубежной — частично, в основном применительно к низковольтным активным выпрямителям вторичных источников питания. Тем не менее, мне удалось разобраться в этом вопросе. И сегодня мы не будем «наобум» выбирать угол , а построим настоящую систему управления 4QS‑преобразователем и смоделируем её работу. При чем не для каких‑то там «детских» мощностей, а вполне в соответствии с потребностями электрической тяги на магистральных линиях.

Продолжить цикл я собирался еще весной, и планировал затронуть именно эту тему, но все откладывал, и свет увидели другие статьи. Однако меня несколько смутил комментарий @AVKinc из предыдущей статьи про 4QS-преобразователь.

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

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

Тон данной публикации задал товарищ @kiltum в своих статьях, начатых с этой. В самом начале был задан вопрос

может ли ИИ заменить программиста?

А действительно? Сколько вокруг этой темы хайпа, нет ни дня чтобы здесь на ресурсе не появилось 100 500 статей на тему нейросетей, LLM, ML и прочего. Пишут много и всякое. Возникло желание проверить лично, насколько решения, предлагаемые ИИ могут быть воплощены в жизнь.

Системы ИИ прочно вошли в нашу жизнь, и да, я тоже ими регулярно пользуюсь. Но мысли программировать с их помощью особо не возникало. Но что если попробовать, поставив при этом задачу из предметной области в которой ты не особо разбираешься? Похожий вопрос ставит и @kiltum, но я хочу попросить автора не ругаться на мою невольную попытку «пообезьянничать». Своей публикацией я лишь хочу подкрепить уже высказанные тезисы, на примере личного опыта. К тому же, старое железо — это всегда интересно, не правда ли? Если так, то добро пожаловать под кат.

В прошлых статьях цикла, а именно

Часть 1, вводная

Часть 2. Более сложные приемы анализа

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

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

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

Среди того, что мне приходилось вести есть такой курс: «Электронная и преобразовательная техника электрического транспорта железных дорог». Специалисту понятно — речь идет о силовой электронике, в самых радикальных её проявлениях. Конечно, для того чтобы не объяснять материал на пальцах, да и для проведения лабораторных работ, в дело идут симуляторы электронных схем. До недавнего времени я использовал LTSpice, однако теперь это невозможно. Но на мое счастье, благодаря vv_kuznetsov, воскрес из мертвых симулятор Qucs. Но с ним не все так просто, как могло бы показаться на первый взгляд.

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

Об этой операционной системе я узнал на данном ресурсе, из многочисленных публикаций её разработчиков. Для тех кто не в курсе - это отечественная операционная система реального времени для встраиваемых устройств с открытым исходным кодом. Её официальный репозиторий расположен тут. Возникло желание опробовать этот проект в деле. Благодаря документации к проекту на виртуальной машине qemu удалось запустить конфигурации для разных платформ. Однако, виртуальная машина - это не для настоящих джедаев).

Тщательно изучив список поддерживаемых одноплатников, остановил свой выбор на Banana Pi M1 с ARM-процессором Allwinner A20. Плата была заказана на Aliexpress, и когда она прибыла, настало время экспериментов. Но всё, как и ожидалось, оказалось не так просто...

Возможно, кто-то из читателей помнит мою серию публикаций о графической библиотеке OpenSceneGraph. Уже на тот момент, в общем-то было понятно, что использование OpenSceneGraph в 2018 году мало оправдано из-за того, что OpenGL, на котором основан OpenSceneGraph потихоньку сдает свои позиции. В феврале 2016 года орган по стандартизации OpenGL Khronos group, выпускают приемника OpenGL - Vulkan API версии 1.0. Производители оборудования в общем-то почти сразу стали добавлять в драйверы своей аппаратуры поддержку нового API. По крайней мере, актуальная на тот момент GeForce GTX 970 уже имела таковую поддержку (про более старые серии аппаратуры ничего сказать не могу).

Не смотря на то, что OpenSceneGraph таки получил поддержку OpenGL 3.x (и ваш покорный слуга собирал его с таковой поддержкой), разработчикам этой библиотеки стало понятно, что огромное количество внутренних проблем OpenGL делает его поддержку бесперспективной. Поэтому, в конце мая 2018 года стартовала разработка новой графической библиотеки VulkanSceneGraph, ориентированной исключительной на Vulkan API. 13 ноября 2022 года состоялся официальный релиз VulkanSceneGraph-1.0, а совсем недавно, 31 августа 2023 выпустили VulkanSceneGraph-1.0.9.

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

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

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

Речь в статье как раз и пойдет об одном из недавних примеров подобной реинкарнации старого железа, прямиком из моей практики. Так что, кому интересно — прошу под кат.

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

Формальной причиной появления этой статьи стала недавняя замечательная публикация "Электрический путь в век скоростей" в которой автор изложил исторические факты о первых, весьма не робких, шагах в развитии высокоскоростного железнодорожного сообщения, предпринятых в Германии в конце XIX начале XX века. Мне, как человеку некоторым образом связанному с железнодорожным транспортом, упомянутая статья понравилась тем, что она осветила, пусть и в публицистической форме, историю первого применения асинхронного двигателя в качестве тягового двигателя железнодорожного экипажа. Впечатляет и масштаб рекорда скорости, достигнутого электровагоном AEG - ведь, на минуточку, дело было в 1903 году! Такой успех технически во многом обусловлен применением именно бесколлекторного двигателя переменного тока.

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

1. Немного общих цифр

Введение