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

1. Собственно сеть или аккумулятор;

2. Индуктивности кабельных линий;

3. Емкости DC звена инвертора;

4. Магнитная система электродвигателя;

5. Кинетическая энергия ротора и механизма.

Дополнительно влияют:

1. Упругие деформации валов или канатов. (Зависит от механизма);

2. Люфты (соединение вала энкодера, например тоже с ними).

При этом один вид энергии может лихо перетекать в другой без вашего желания. Заметим в системе будет оставаться энергия даже когда отключен аварийный автомат! Например разогнали паровоз электродвигатель с постоянными магнитами, что то случилось, отключили контактор, закрыли транзисторы инвертора, но двигатель разогнан и является уже генератором, который с пламенем открытым может разрывать транзисторы. И получить ток КЗ в килоамперы можно от небольшой машины. /например Капица П.Л., специально загонял машину в такой режим, для получения в пике 50МВт на нагрузке.

Все указанные факторы должны быть отработаны, и получено требуемое качество регулирования электропривода, а настройка САУ это всегда творческий процесс. Один из моментов плясок с бубном работы с приводом я и расскажу.

Было это на заре туманной юности когда работал в интересной фирмочке ООО НПФ Интехсиб, г. Новокузнецк. (Фирма есть эта и ныне, занимается тем же, но формат работы несколько изменился.) Базовые принципы работы фирмы:

1. Только аналоговые системы управления. Допускается только КР140УД708, LM2904, LM358, BC817/807, КТ837Ф, ну и реле SHRACK;

2. Каждый узел, должен быть custom;

3. Только нормальные читаемые схемы с номиналами, без миллиона переходов с листа на лист и непонятных бесконечных кубиков. /ЕСКД в топку/;

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

Несмотря на любовь к аналоговой схемотехнике, до внедрения стандарта обязательного наличия на шахтных подъемных машинах электронных регистраторов, была разработана своя аппаратура еще в далеком 2004г. Для понимания масштабов это ЦШ 5х8. Каждый «моторчик» около 5-6МВт.

1. Шкаф плавного разгона преобразовательного агрегата Генератор-Двигатель (бережем синхронный двигатель и электроэнергию)

2. Тиристорная сборка плавного пуска

3. Возбудитель синхронного двигателя

4. Шкаф релейный (99% объема шкафа клеммники для подключения огромного количество кабелей, а сама автоматика все остальное 3 блока всего размером)

5. Реверсивный возбудитель генератора( с системой регулирования скорости привода, фото выше)

6. Возбудитель подъемного двигателя

7. Пленка сверху, так как вода с крыши капает.

Аппаратура давала примерно вот такие картинки:

Скажу сразу, что это не прокатный стан и главное - минимальные переходные процессы.

Частота сэмплов была примерно 10-15Гц, запись была круглосуточной, с архивом на годы. На компах того времени. Отстраивать САУ с того момента стало очень удобно.

В 2014г. после перехода на «вольные хлеба», был интересный заказ. Сервопривод на базе SRM машины. Доделать его не получилось по многим причинам, но сам электродвигатель получился отличный и даже родилось искусство проектирования SRM /Иногда очень полезно не копировать и не смотреть как делают другие./. Проблема таких машин в том, что они имеют большую пульсацию момента, шумят, преобразователь сложный и нестандартный, тем не менее делать можно, если не идти напролом и не пытать все выправить электроникой.

Ключевой проблемой настройки стало отсутствие мониторинга с высокой частотой сэмплов.

С одной стороны с точки зрения электроники электродвигатель такое медленное устройство, с другой транзистор за 10мкс сгорает при аварийных процессах. И страшно не то что сгорело, а когда понять невозможно. А почему сгорело?

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

В 2020г. Было сделано вот этот вариант. Концепт устроил, но довести до ума так и не удалось.

https://github.com/gravl4/ADC_UDP_LOGGER

и генератор потока https://github.com/gravl4/ADC_UDP_STREAM_LPC1778

Основные изменения, это интерфейс — Ethernet. Плюсы

1. Он везде есть и одинаковый!

2. Нет проблем с драйверами;

3. Нет проблем со скоростью;

4. Дополнительная гальваническая изоляция;

5. Легко работать на программном уровне как со стороны ПК так и МК;

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

1. Ethernet или WiFi интерфейс, UDP протокол;

2. Медленные сэмплы 1кГц-10кГц, «аварийные» сэмплы до 1МГц;

3. Время записи до 20мин или 3-5млн. измерений;

4. Два аналоговых окна, синхронизированных по шкале;

5. Масштабирование, перетаскивание;

6. Сохранение настроек и осциллограмм;

7. Desktop, Linux, Rust;

8. 16 аналоговых каналов;

9. 32 цифровых;

10. Частота кадров не менее 20Гц;

11. Timestamp ставит микроконтроллер;

В инверторе есть массив сэмплов с частотой работы основного цикла и некоторые важные каналы даже выше. Пока нет аварии или синхроимпульса, данные идут медленно. Из массива берутся не все сэмплы. Если есть аварийное событие или синхроимпульс, то выдаем весь массив с разрешением до 1мкс. Дальше думаем почему что то случилось или почему САУ дергается.

Почему так сложно:

1. Поток данных в моем случае на 1МГц — 50МБайт/с - 60ГБайт/20мин, все сохранить и обработать на данном этапе собственного развития, не реально.

2. В отличие от видео на осциллограмме надо смотреть как всю запись за 20мин, так и микросекунды, либо как то посередине. Это либо весь «фильм» в один кадр преобразовать, либо 100кадров в один пересчитать либо покадрово вручную пролистывать.

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

Начались поиски подрядчиков, было интересно понимать, как не любят Rust. Почему именно он?

1. Руководитель всегда прав;

2. Rust заставляет тебя обрабатывает исключения. Как эмбеддеру мне просто феноменально это нравиться. У меня в эмбеде целевой код это 1-5%. Остальное либо инструментарий, либо обработка событий датчик отвалился, что делать? Или пришли данные битые, как быть? Модуль связи не отвечает на AT команды. и т. д.

Вообще Rust и UI это слезы. Тем не менее после хелло ворлд выделил три. slint, egui, gpui

Slint отпал так как предлагает еще один свой язык. Мне как эмбеддеру хватает заклинаний: С, ASM, Make, GDB, Скрипт линкера, Json для VSC

Еще в один вникать не хотелось совсем, отдавать на откуп подрядчикам и за каждым чихом их вызывать тоже. Пришлось взяться за программирование для ПК самому, 25 лет спустя после Delphi в институте.

Очень впечатлил gpui, но пришлось отказаться так как нативного plot нет, а plotter медленная библиотека когда пару тысяч точек на канал. Сильно хотелось свой plot сделать в философии gpui на wgpu, но как всегда время/ресурсы.

Тестировались разные подходы:

1. Gnu plotter + minifb — внешняя программа, получалось медленно

2. просто minifb — быстро, но нужно свои компоненты создавать или с тем же egui совмещать

3. egui + wgpu — хорошо, так миллионы точек все равно не обработать

Остановился в итоге на egui + rayon + egui_plotter = готовить максимум 2000 точек на канал + максимально параллельные вычисления. egui_plot по факту пришлось делать свою сборку.

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

Параметры:

1. Пакеты UDP;

2. 16 аналоговых/32 цифровых, все в настраиваемых цветах;

3. Все масштабируется, перетаскивается;

4. Conversion — это пересчет в физическую величину, Reduction — это масштабирование на графике. Иногда надо 100А смотреть вместе с 10000об/мин

5. Осциллограммы, настройки можно сохранять открывать.

Баги как обычно есть, но пользоваться уже можно. Из-за egui жрёт ресурсы как не в себя, но делать нечего :-(. Сборка выложена здесь BUILDS. Исходники здесь.

Сборка сделана в отладочном варианте, поэтому размер ну вот такой большой :-) Планы по развитию (при наличии ресурсов естественно)

1. Настройка параметров привода из программы мониторинга

2. Режим простого осциллографа

3. Перенести на gpui и сделать свой wgpu основанный plot компонент