Применение ООП принципов в программе

[Shatoshi]

Добрый вечер!

В настоящее время я работаю над программой, которая должна управлять источниками питания устройств и отслеживать параметры с помощью DAQ-карт (преимущественно NI). Поскольку устройства работают автономно в течение длительного периода времени, программа также включает в себя циклограммы, ПИД-регуляторы и проч. Очевидно, что у оператора должна быть возможность отслеживать параметры и вносить изменения в процессе работы системы. Существует вероятность того, что источники питания будут меняться во время работы, в то время как периферийные устройства (вакуумные датчики, затворы, клапана и т.п.) не будут. В процессе разработки я пытаюсь применять принципы ООП.

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

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

II. В DAQ-части у меня сразу же возникли трудности с реализацией уровня аппаратной абстракции. Моя идея заключалась в создании абстрактного класса DAQType, от которого наследовались бы AI/AO/DI/DO задачи. К посту приложил диаграмму, которая иллюстрирует эту идею.
Кажется, что создавать абстрактный класс-родитель - плохая идея, поскольку "магии полиморфизма" здесь очень тяжело добиться. Да и в целом, архитектура DAQmx сама по себе похожа на своего рода HAL Вопросы:

1. Стоит ли цепляться за классы для каждого типа задачи, или же следует оставить эту идею?
2. Во время работы могут меняться группы подключенных сигнальных линий ввиду нехватки каналов. Стоит ли хранить состояние (unreserved, reserved..) в качестве атрибута в каждом классе, чтобы было удобнее работать с экземплярами классов? Для изменения конфигурации задачи её нужно явно переводить в состояние unreserved (если не ошибаюсь), что и наводит меня на эту мысль.
3. Касательно задач AI и DI: обратите внимание, что на диаграмме, которую я привел выше, в абстрактном классе присутствует метод Perform(), который для AI и DI должен выводить данные разных типов (например, массив double для AI и массив boolean для DI). Значит, что панели подключений у наследников будут отличаться, что нарушает принцип наследования. У меня не вышло придумать подходящую реализацию для метода Perform(). Может быть следует хранить полученные в результате опроса данные в полях самих классов? Еще одна идея - это использовать полиморфные VI, что позволит сохранить типизацию.
4. Как следует передавать объекты в основной программе: тянуть линии (т.е. по значению) или ссылками (например, оборачивать объект через data value reference)? Есть ли подводные камни, связанные со сборщиком мусора, о которых следует задуматься?
5. Похожий вопрос относительно получаемых данных в ходе опроса DAQ-карт: их следует предоставлять через т.н. метод Get (как поле класса) или же также оборачивать через data value reference, чтобы передавать набор данных ссылками? Отмечу, что мне нужно только читать свежие данные, а не копить их.

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

Заранее признателен за уделенное время!

[IvanLis]

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

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

Начнем по порядку и по мере появления времени.
Что касается модели программирования.
У Вас тут хорошо ложиться Actor Framework, там и асинхронность процессов (Акторов) и классы и наследование и пр., но высокий уровень вхождения.
В принципе если отвечать на Ваш вопрос, то все циклы на БД работают асинхронно, фактически каждый в своем потоке.
Если брать например LabVIEW. Стиль программирования, там предлагается подобная модель (желательно посмотреть книгу самостоятельно).

тут на рис. 8.30, каждая SubVI имеют встроенный цикл, который работает асинхронно с остальными.

------------- что касается ООП -------------
Можно рекомендовать все что угодно, но пока не совсем понятно для чего вы разделяете Write & Read, это различные физические устройства?

[Shatoshi]

У Вас тут хорошо ложиться Actor Framework, там и асинхронность процессов (Акторов) и классы и наследование и пр., но высокий уровень вхождения.
В принципе если отвечать на Ваш вопрос, то все циклы на БД работают асинхронно, фактически каждый в своем потоке.
Если брать например LabVIEW. Стиль программирования, там предлагается подобная модель (желательно посмотреть книгу самостоятельно).
Снимок экрана от 2025-07-14 22-16-11.png
тут на рис. 8.30, каждая SubVI имеют встроенный цикл, который работает асинхронно с остальными.

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

------------- что касается ООП -------------
Можно рекомендовать все что угодно, но пока не совсем понятно для чего вы разделяете Write & Read, это различные физические устройства?

Да, это разные устройства: AO используется, например, для задания расхода в регуляторе расхода газа, в то время как AI отображает потенциалы элементов испытываемого устройства.
Если я неверно понял Ваш вопрос, то не могли бы Вы его переформулировать, пожалуйста?

Спасибо!

[FredP]

Привет. Не претендую на истину, выскажу свое мнение.
В работе инженера по автоматизации стендовых испытаний главное - сэкономить время. Стенд должен быть готов как правило, быстрее чем тестируемое изделие. Я для себя вывел основной способ делать быстро - это максимально использовать шаблонные решения, причем, в минус универсальности. Если утрировать, то "тяп -ляп и в продакшен, приступаем к следующем стенду". Поэтому использовать классы, AF - не советую. Если ПО будет куда то передаваться (заказчику) то классы и AF вообще использовать нельзя. Большинство LV инженеров их не знает и они не смогут поддерживать программу. Будет много звонков.
Теперь к делу:
Однозначно архитектуру советую QMH. Пример в LabVIEW встроенный - crate project - Queued Message Handler. Правда, я перешел на немного более удобный тулкит AMC QMH. Смысл тот же самый что и NI QMH https://www.vipm.io/package/ni_lib_amc/
Но это общая архитектура, еще нужен GUI, сохранение настроек. Это все рекомендую взять из примера Continuous Measurement and Logging.
Вот, для каждого прибора создаю свой обработчик. Если понадобится заменить один прибор на другой - просто нужно заменить виайку обработчика. Если несколько одинаковых - тогда скопировать.

Следующее: обмен данными между обработчиками. Для команд я использую QMH, а для данных NI CVT https://www.vipm.io/package/ni_lib_cvt/
Плюсы: никаких проводов, адресация по имени. Записал "Напряжение БП1 канал 1" и прочитал в другом месте. Удобно и человекочитаемо.
Теперь самая важная часть: собственно, управление приборами, составление циклограмм.
Рекомендую CompactRIO Temperature Controller Reference Application https://forums.ni.com/t5/Example-Code/C ... -p/3984225
1 Разработан удобный способ построения алгоритма без программирования, и выполнения алгоритма.
2 Поддерживается RT. Для систем управления очень важно.
Внешний вид программы я значительно переделал для себя. Делюсь шаблоном:

Шаблон стенда тестирования.zip

(4.26 МБ) 58 скачиваний

Шаблон стенда управления.zip

(638.66 КБ) 60 скачиваний

[Shatoshi]

Добрый вечер, FredP!

Благодарю за содержательный ответ! Со всеми пакетами, что Вы порекомендовали, обязательно ознакомлюсь в ближайшее время. То, что Вы привели в пример свой подход к разработке программ, разложив все по полочкам, для меня очень полезно.

Внешний вид программы я значительно переделал для себя. Делюсь шаблоном

Как только доберусь до среды разработки, просмотрю шаблоны, которыми Вы поделились. Обязательно вернусь с обратной связью!

Большое спасибо!

[Shatoshi]

Добрый день, FredP!

Кратко ознакомился со всем, что Вы приводили, кроме CompactRIO Temperature Controller Reference Application. Архитектура QMH + CML действительно хорошо подходит для большого количества задач. Кроме того, пока я искал информацию, наткнулся на фреймворк DQMH. Судя по всему, это усовершенствованная версия QMH, которую поддерживают сторонние разработчики и сообщество. Хотел узнать, рассматривали ли вы работу с DQMH?
Также хотел отметить, что шаблоны, которые Вы привели, очень удобные. Они вместе с существующей в сети информацией помогут быстро влиться в архитектуру. Думаю, что после реализации пары тестовых проектов на NI QMH, потыкаюсь с AMC QMH. Впоследствии буду пробовать DQMH.

[FredP]

Рад поделиться полезным! DQMH пробовал. Не могу сказать что это усовершенствованный QMH. Скорее, есть три ветки: NI QMH, AMC QMH, DQMH. Второй не требует протягивания провода от кластера ссылок очереди. Эту ссылку можно получить "на месте" по текстовому имени. Опять же, такой подход уменьшает читаемость (вложил где нибудь в кадре его и не найдешь куда он что сам посылает-принимает), но, позволяет делать "быстрее" не протягивая провод ко всем виайкам. Но приходится заплатить тем что он принимает только string. Нужно ставить дополнительный ВП.
Про DQMH: там жуть с гуёвым конфигуратором сообщений, все на классах, даже у LV разработчика выше среднего вызывает нежелание разбираться. После NI QMH один вопрос: зачем это все? Нормально же общались ;)

В общем на вкус и цвет все фломастеры разные.

[FredP]

Кстати, мне понравилась заметка вот этого автора https://delacor.com/my-journey-through- ... -and-dqmh/ . Мне кажется, мой опыт очень похож на его.
Особенно это:

I then had a customer asking me to develop an application that would need to be maintained, expanded, and upgraded in the future by LabVIEW newbies. I had to explain AF to newbies. Even though my explanations might have gone through with some of them, I could see a lot of bewildered eyes.

И это:

I also thought that I missed the object-oriented nature of the AF actors. I realized though that the ability to create abstract actors, which I had used, was interesting in theory but never had been really useful in any of my projects