Созерцаем электропривод

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

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 ^[1]

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

Основные изменения, это интерфейс — 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 но отклонили ^[3]. Немного не устраивал их штатный режим автомаштабирования. Данные решил обрабатывать следующим образом. Меня как разработчика интересуют не значения, а экстремумы. Алгоритм берет интервал времени приходящийся на 1 пиксель, определяет мин и максимум, и оба идут в отображение. Результат трудов:

Параметры:

1. Пакеты UDP;

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

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

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

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

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

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

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

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

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