LabVIEW Portal

Всем привет.
В поисках решения вопроса в задаче, которую мне нафантизировал шеф.
Имеем некий GUI для управления двумя устройствами посредством USB COM. Устройства по своей логике и управлению полностью идентичны с той лишь разницей что у них команды по одним и тем же функциям, передаваемые и считываемые разные. На данный момент построены 2 sub vi. , которые ничем друг от друга по функционалу и дизайну не отличаются и запускаются юзером поочередно из главной vi, в зависимости от того, каким прибором нужно управлять.
Шеф поставил задачу все построить под одной vi в которой в зависимости от того каким прибором нужно управлять, присутствует селектор в виде элемента управления Text Ring. Таким образом необходимо менять все значения в стрингах, а так же конфигурациях COM (Visa) не затрагивая элементы контроля и управления на передней панели.

Логика управления имеет множественные вложенные иерархические конструкции с разными структурами. Обращения к COM не объединены одной структурой.

Такое реально и насколько это логично по отношению к существующему метоу с sub.vi или это просто бессмысленный полет фантазии шефа?

Select писал(а):Такое реально и насколько это логично по отношению к существующему метоу с sub.vi или это просто бессмысленный полет фантазии шефа?

Реально все, зависит только от сил и времени, которое Вы готовы затратить на реализацию.

Если прям совсем правильно делать, то можно использовать возможности ООП.
Будет у Вас класс "Устройство" описываете свойства и методы.
От базового класса делаете двух наследников: "Устройство-1" и "Устройство-2". Переопределяете методы. Получатся своего рода полиморфные функции, которые в зависимости от класса на входе, будут по разному работать.
Дальше по логике....

Посмотрите стандартные примеры, например .../Graphics/Graphics - A Basic Class Hierarchy.lvproj
как там работает глобальная функция Render Picture.vi

Даже приблизительно не представляю, как можно средствами выполнить инкапсуляцию всех объектов.
Нашел пример на который Вы сослались
c:\...examples\Object-Oriented Programming\Graphics\Graphics - A Basic Class Hierarchy.lvproj
Попробую вкурить.
Благодарю за совет.
Единственный открытый вопрос, насколько и в каих случаях это оправдывает себя?

Select писал(а):Единственный открытый вопрос, насколько и в каих случаях это оправдывает себя?

У Вас же сейчас все работает и без ООП...
А целесообразность и необходимость за Вас сформулировали

Я например ни разу в проектах не использовал ООП, за исключением сторонних уже готовых классов.
Но это дело вкуса, привычки и тема другого разговора, например http://labviewportal.org/viewtopic.php?f=23&t=191

Сделал небольшой пример.
Делал в 2016, пересохранил в 2014, надеюсь откроется. Получилось так: Методы Connect и Get Data я переопределил.
Disconnect переопределять не стал, т.к. там входные данные и действия одинаковые.
Set Data - оставил Вам поиграть.

Принцип думаю понятен, дальше нужно наращивать...

Что касается инкапсуляции, это не самое сложное и реализуется просто, правда кажется нудным, т.к. прямого доступа пользователь к свойствам не имеет, а модифицировать и читать их может через реализованные Вами интерфейсы (методы), получается по два на свойство

Посмотрите еще материалы: https://www.viewpointusa.com/TM/ar/labv ... ool-chest/

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

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

Хотелось бы вернуться к теме, открыл параллельную ветку в разделе
Насколько LTE Application Framework прост в освоении, насколько он универсален, с чего начинать, любые советы и рекомендации.