Actor Framework

Общие принципы, проектирование, модуляризация, темплейты и шаблоны

Re: Actor Framework

Postby Vitekkz88 on 20 Nov 2017, 04:59

Kosist писал(а): А вообще, интересно сколько людей на портале сейчас использует AF в проектах? Или что-то подобное, типа JKI SMO?..

Сдаётся мне, что таких разработчиков не очень и много. Не, конечно же все об этом слышали, видели и смотрели примеры...но не так, чтоб перетаскивать проекты на Actor-ы. Не потому что Actor плохой, а скорее просто "а зачем?! Может это кому-то удобно, наглядно и т.д., но я по старой школе проекты делаю: дерево проекта, штук N папок, паттерн Produce-Consumer или машина состояний и вперёд. Этот подход покрывает подавляющее большинство решений задач по сбору данных и по автоматизации лично у меня. Как-то читал, что Actor полезен для ооооочень большого проекта, типа попроще будет между разработчиками передавать исходники и разработку вести. По своему опыту: и без Actor-ов всё норм, чесслово! :crazy:
Если захочется экзотики, то может быть когда-нибудь и Actor гляну, но не более того ибо "а зачем?". Классическое ООП-программирование я и без этого знаю, захочу нормальной ООП софтины - я её на Java сделаю или на C++. А пока мне не охота хапнуть разочарований по части представления ООП в LabVIEW. Поэтому даже примеры не смотрю, но за предложенный вопрос для небольшого оффтопа - спасибо! :drink:
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby taras_33 on 20 Nov 2017, 15:45

to Vitekkz88 Года три назад у меня было точно такое же мнение, которое координально изменилось, после того как программист от NI преподал мне мастер класс, за деньги компании, где я работаю. Моя жена в прошлом тоже говорила "нафига мне этот смартфон, телефон предназначен в первую очередь что бы звонить, а не...." Теперь попробуй отними у нее ее sony...
AF кстати и есть Producer-Consumer, только продвинутый. Насчет OOP зря Вы так. Впрочем у каждого свое мнение....
То, что мы знаем-------ограничено, а что не знаем------бесконечно!
User avatar
taras_33
advanced
advanced
 
Posts: 152
Joined: 31 Oct 2009, 18:25
Location: Minsk -> Miami
Medals: 1
Activity (1)
LabVIEW Version: 2016
Karma: 82
CLD

Re: Actor Framework

Postby Vitekkz88 on 20 Nov 2017, 18:36

taras_33, смартфоны и всё такое - это не про то. Что есть продвинутого в Actor-ах для паттерна Produce-Consume, это же всего лишь паттерн. Паттернов проектирования существует множество, Produce-Consumer это лишь частный случай модели программирования , но он отлично ложится на проекты по сбору данных (одна из основных фишек LabVIEW). А что не так с ООП? :D Неужели Actor позволяет реализовать полиморфизм, наследование, инкапсуляцию? Во что это выливается с точки зрения программного представления и сопровождения? Про абстракцию понятно...Я просто интересуюсь у вас, как у более опытного в этом деле, человека. Не ищите в моих словах стёба или желания опустить одни технологии в угоду другим.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby Kosist on 20 Nov 2017, 20:15

Vitekkz88, Actor - это по-сути класс. Поэтому, он естественно позволяет реализовывать все "фишки" ООП - полиморфизм, наследование, инкапсуляцию, и т.д.
В чем "продвинутость" Actor Framework (AF) по сравнению с Producer-Consumer? Во-первых, AF реализует Command Pattern - это когда каждый стейт стейт машины является классом (обычно, с двумя методами - Send: для посылания комманды; Do - для выполнения). А если это класс, то и для него можно реализовывать ООП "фишки".
Во-вторых, AF - т.к. это фреймворк - при помощи Chanelling Pattern (это когда метод имеет внутри другие методы, которые можно переписать (override), и таким образом гарантируется порядок выполнения алгоритма) реализует обработку стейт машины: прием сообщений (механизм которого тоже можно переписать), выполнение стейтов (или, более правильно, сообщений/команд), и обработка ошибок. Это только стейт-машина. А в целом - AF уже имеет готовую обработку динамического, асинхронного запуска акторов, их остановку; отслеживание работы вложенных акторов, и т.д. То есть все это не нужно создавать/копировать снова и снова.
В третьих, если актор - это класс, который имеет методы, которые могут быть "переписаны" его дочерними акторами/классами, то мы можем унаследовать не просто функционал одного метода, а целую логику модуля; проще говоря - унаследовать целую стейт-машину. И плюс ко всему, добавить к ней функционал. Это, по моему, самое главное в AF - если в просто классе дочерние классы унаследуют методы, то акторы позволяют унаследовать полностью функционал. На словах тяжело объяснить, советую посмотреть конкретные примеры, и презентации.
Таким образом, например, если в методе Handle Errors.vi главного класса имплементировать обработку ошибок (запись в файл, кастомное диалоговое окно, и т.д.), то его дочерние акторы будут иметь тот же функционал. А это уменьшает количество кода, и повышает его модулярность, reusability, и т.д.
При стандартном подходе Producer-Consumer, придется все это делать каждый раз для каждой стейт машишы/модуля. Конечно, можно использовать подпрограммы, копировать код, и т.д. Но все это не эффективно, по сравнению с ООП.
Ну, и т.к. сообщения (команды) к акторам являются классами, как я писал выше, то с ними тоже можно "поиграться" с ООП точки зрения. Например, Zero Coupled Abstract Messages, Low Coupled Abstract Messages - это вообще отдельная тема.
Но, само собой, есть и минуса.
Первое - при неправильной архитектуре в целом, можно здорово запутаться, и акторы будут лишь во вред, а не на благо. Нужно мыслить "объектно", на уровне абстракций. Только тогда можно выжать из акторов максимум. А если рассматривать их только как стейт-машину, то далеко не заехать...
Второе - это количество классов/методов в проекте. Если метод актора должен "отсылаться" на выполнение, то это + класс с 2-мя методами.
На NI форуме есть презентации на тему альтернатив акторам, JKI вообще сделали свою SMO (state machine objects) - где их JKI State Machine используется как ядро класса, и т.д.

Как-то так...

А насчет ООП в :labview: - это Вы зря... Да, по сравнению с "традиционными" языками, такими как С++, Java, Ruby, Python, может :labview ООП реализация не дотягивает до их уровня , но все равно, позволяет создавать отличные вещи. Элементарный пример - HAL, абстракция железа. Вы ее используете в проектах? Если да, то тоже без классов?
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby taras_33 on 20 Nov 2017, 21:48

Kosist, Спасибо, я бы лучше не написал. Пожалуй единственное, чего лично мне не хватает в LabVIEW-шном ООП, так это множественного наследия, которое в других языках есть. Другими словами у ребенка не может быть двух родителей, поэтому приходится обходится дедушками и прабабушками :D
То, что мы знаем-------ограничено, а что не знаем------бесконечно!
User avatar
taras_33
advanced
advanced
 
Posts: 152
Joined: 31 Oct 2009, 18:25
Location: Minsk -> Miami
Medals: 1
Activity (1)
LabVIEW Version: 2016
Karma: 82
CLD

Re: Actor Framework

Postby Kosist on 21 Nov 2017, 00:30

taras_33 wrote:Kosist, Спасибо, я бы лучше не написал. Пожалуй единственное, чего лично мне не хватает в LabVIEW-шном ООП, так это множественного наследия, которое в других языках есть. Другими словами у ребенка не может быть двух родителей, поэтому приходится обходится дедушками и прабабушками :D

Спасибо!
По поводу множественного наследования - честно, я его никогда не использовал (т.к. в текстовых языках я особо не программирую), но бывали случаи, когда думал, что "Эх, вот бы этот класс наследовал функционал от того и этого класса"... Но, к сожалению, как Вы и написали, "напрямую" делать это нельзя. Нужно либо "впихать" в один класс несколько других классов (например, Switch Measure Unit работает как мультиметр, и мультиплексор, поэтому состоит из двух классов для DMM и MUX); или можно разбираться с примерами от Дмитрия Сагателяна, по поводу Facade паттерна... Хотя к нему, честно говоря, руки у меня так и не дошли...
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby Vitekkz88 on 21 Nov 2017, 06:12

Kosist писал(а):Таким образом, например, если в методе Handle Errors.vi главного класса имплементировать обработку ошибок (запись в файл, кастомное диалоговое окно, и т.д.), то его дочерние акторы будут иметь тот же функционал. А это уменьшает количество кода, и повышает его модулярность, reusability, и т.д.
При стандартном подходе Producer-Consumer, придется все это делать каждый раз для каждой стейт машишы/модуля. Конечно, можно использовать подпрограммы, копировать код, и т.д. Но все это не эффективно, по сравнению с ООП.

1.На минуточку, а у Вас в программах часто смешиваются два паттерна? Машина состояний и produce/consumer? И много машин состояний(10,20, сколько в пике было?).
Про обработку ошибок: я их в отдельную очередь сгружаю все и поднимаю в отдельном потоке с subVI для которой как раз есть отдельный интерфейс. В чем неудобство иметь отдельную очередь для обработки ошибок с отдельным subVI?
2. Что значит копировать код? Я прекрасно справляюсь с созданием логически завершенных SubVI. И их проще сопровождать, документировать и допиливать. Это аккуратно оформленный код, всё как надо с комментариями. Взял и поставил, дел на 3 секунды. SubVI - это и есть метод некоторого класса.
3. Доступы к полям и методам класса как-то регламентируются в Actor-е? Как там с защитой полей?
4. Вся эта история с Actor-ами переносится в Real-Time? И на сколько использование Actor-ов замедляет работоспособность программы в целом? Неужели нет проигрыша?
Kosist писал(а):Элементарный пример - HAL, абстракция железа. Вы ее используете в проектах?

5. Про HAL не понял. Вообще про такое не слышал, если честно...простите :dntknw:
Пример: у меня в программе используется 5 разных типов оборудования(подключенных по USB, Ethernet). Для каждого устройства у меня отдельный поток взаимодействия. Где тут что абстрагировать? Они и так в отдельных потоках сидят и ждут своих команд или данные сливают в потоки обработки. Куда уж проще и понятней-то с точки зрения LabVIEW? Зачем для этого дела создавать отдельный класс и методы? :D
Kosist писал(а): Но, само собой, есть и минуса. Первое - при неправильной архитектуре в целом, можно здорово запутаться, и акторы будут лишь во вред, а не на благо.

Какой-то странный минус, если честно, он общего плана. При неверной архитектуре можно с любой технологией сесть в калошу :crazy: Меня интересуют более фундаментальные недостатки, к которым относится минус номер 2.
Kosist писал(а): Да, по сравнению с "традиционными" языками, такими как С++, Java, Ruby, Python, может :labview ООП реализация не дотягивает до их уровня , но все равно, позволяет создавать отличные вещи.

Actor-ы подойдут для проектов, в которых over100500 машин состояний, много оборудования, еще больше генераторов данных и обработчиков. Проект эдак на 1000+ .vi и это только на верхнем уровне, неизвестно как акторы себя в real-time ведут. Хотя, с другой стороны, всё можно сделать и без Actor-ов.
Я просто хочу понять выгоду перехода на этот подход. Если выгода перехода с языка программирования С на C++ очевидна, то профит от перехода с традиционного LabVIEW на LV+Actor-фреймворк как-то не очевиден. Уменьшение кода - это по части LabVIEW так себе аргумент, нужно уметь писать аккуратно и грамотно заворачивать всё в subVI. Дерево проекта опять же будет раздуваться, да? Да! Так же, как если бы мы использовали subVI. Никто же не пишет, например в С++, программу а-ля Hello Worl с использованием ООП? Верно, не пишет. Но на Java это по умолчанию, например. ООП проявляет себя в полной красе на больших проектах. Я абсолютно уверен, что в LVOOP всё точно так же, иначе и быть не может. Только в качестве программы Hello World в LabVIEW может быть программа для управления и сбора данных. А вот если бы мы это делали на классическом языке программирования с ООП, то обязательно бы создали класс "Железо" и методы класса, разграничивали бы доступ к полям и т.д.. В этом вся разница, не надо усложнять то, что и так прекрасно работает, легко реализуется/сопровождается.
Пока что я понял так: Actor поддерживает некоторые паттерны, но с другой стороны в этом легко запутаться, да и в целом паттерн - штука абстрактная в классическом понимании. Это просто шаблон с набором правил и рекомендаций, которые были выработаны путём анализа больших проектов с долгосрочной перспективой(аля Enterprice). Да, Actor позволяет реализовать ООП, но опять же не дотягивает до других ООП(а в чем не дотягивает то? "отсылка" метода = + класс с 2 методами? в этом плане что ли?).
Закончу своими же словами еще раз:
Vitekkz88 писал(а):, Я просто интересуюсь у вас, как у более опытного в этом деле, человека. Не ищите в моих словах стёба или желания опустить одни технологии в угоду другим.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby Kosist on 21 Nov 2017, 09:18

Vitekkz88 wrote:1.На минуточку, а у Вас в программах часто смешиваются два паттерна? Машина состояний и produce/consumer? И много машин состояний(10,20, сколько в пике было?).

Но Producer-Consumer и есть тоже стейт машина. Классический паттерн имеет цикл для генерации комманд (Producer), и второй цикл для их выполнения (Consumer). А Consumer как раз реализован как стейт машина? Хотя согласен, Consumer может и не содержать стейт-машины, но если Вы посылаете в него комманды, то это уже стейт машина.
Vitekkz88 wrote:Про обработку ошибок: я их в отдельную очередь сгружаю все и поднимаю в отдельном потоке с subVI для которой как раз есть отдельный интерфейс. В чем неудобство иметь отдельную очередь для обработки ошибок с отдельным subVI?

Нет отдельной очереди на обработку ошибок. Посмотрите скрин, увидите, что я имел ввиду. Обработчик ошибок - уже часть цикла.
af core.PNG

Vitekkz88 wrote:2. Что значит копировать код? Я прекрасно справляюсь с созданием логически завершенных SubVI. И их проще сопровождать, документировать и допиливать. Это аккуратно оформленный код, всё как надо с комментариями. Взял и поставил, дел на 3 секунды. SubVI - это и есть метод некоторого класса.

Да, но если Вам нужно в библиотеке Б использовать цепочку из виаек библиотеки А, например, так (в порядке вызова):
VI1 - VI2 - VI3
и нужно изменить функционал VI2, как Вы поступите? Скопируете VI1, VI3 в либу Б, а вместо VI2 создадите новую? На "лету", динамически ведь не удастся заменить ее. А в случае ООП все просто - VI2, это dynamic dispatch виайка, которую дочерние классы просто могут переписать. И цепочка VI1 - VI2 - VI3 останется не тронутой для основной программы, ее функционал будет менятся динамически во время выполнения. Т.е. Вы изменяете код отдельных модулей, не трогая основной программы.
Это большое преимущество по сравнению с традиционным подходом, ведь в трад. подходе больше "завязанность" на интерфейсы виаек, входа-выходы. А в случае классов Вы работаете с интерфейсами. И тогда замена функционала происходит менее болезненно.
Vitekkz88 wrote:3. Доступы к полям и методам класса как-то регламентируются в Actor-е? Как там с защитой полей?

Так же, как и везде. Если будет создан accessor, то к данным можно будет достучаться. А так - данные приватные, это уже дело разработчика, к чему создавать доступ. Повторюсь, актор - это класс, со всеми вытекающими.
Vitekkz88 wrote:4. Вся эта история с Actor-ами переносится в Real-Time? И на сколько использование Actor-ов замедляет работоспособность программы в целом? Неужели нет проигрыша?

Да, переносится. Но есть одно но. Очередь, по которой акторы передают сообщения-команды, в 4 раза медленней стандартной очереди. Поэтому, если нужна быстрая коммуникация, в акторах есть понятие Helper Loop. Плюс ко всему, никто не запрещает использовать модули акторов с не-акторами.
Vitekkz88 wrote:Про HAL не понял. Вообще про такое не слышал, если честно...простите :dntknw:
Пример: у меня в программе используется 5 разных типов оборудования(подключенных по USB, Ethernet). Для каждого устройства у меня отдельный поток взаимодействия. Где тут что абстрагировать? Они и так в отдельных потоках сидят и ждут своих команд или данные сливают в потоки обработки. Куда уж проще и понятней-то с точки зрения LabVIEW? Зачем для этого дела создавать отдельный класс и методы? :D

Советую загуглить "labview hardware abstraction layer". Вкратце. Сегодня заказчик сказал, что программа должна общаться с контроллером по TCP/IP, а завтра - через ком порт. Сегодня в качестве мультиметра используется NI железо, завтра - железо от Agilent. А значит, разные протоколы, разные драйвера. При помощи плагин архитектуры, в софте я использую общие, абстрактные методы для работы с железом, а во время рантайма определяю, какой плагин будет выполняться. Таким образом, можно проганять целую программу на симулируемом железе, а можно одним кликом переключить на реальное. Вот это и есть абстракция железа - софт использует абстрактные методы, а конкретную имплементацию Вы задаете такую, какую нужно.
Может я объясняю и путано, но тогда советую посмотреть презентации.
HAL в любых языках вещь полезная и нужная, тут даже нет никаких сомнений. Особенно, если нужно делать симуляцию железа - т.к. "живое" железо еще не готово/не собрано/не подключено, а программу в целом тестить надо. Что тогда - скипить участки кода? Кейс структуры?
Vitekkz88 wrote:
Kosist писал(а): Но, само собой, есть и минуса. Первое - при неправильной архитектуре в целом, можно здорово запутаться, и акторы будут лишь во вред, а не на благо.

Какой-то странный минус, если честно, он общего плана. При неверной архитектуре можно с любой технологией сесть в калошу :crazy: Меня интересуют более фундаментальные недостатки, к которым относится минус номер 2.

Тут согласен, неудачный пример.
Vitekkz88 wrote:Да, Actor позволяет реализовать ООП, но опять же не дотягивает до других ООП(а в чем не дотягивает то? "отсылка" метода = + класс с 2 методами? в этом плане что ли?).

Не совсем. Например, в LV OOP отсутствует множественное наследование. Но не большая беда, т.к. в некоторых текстовых его тоже нету.
Тогда, скажем, в Python есть куча готовых методов типа __init__, __repr__, __call__, и т.д., которые доступны всем классам без исключения, и позволяют их переписать. В LV, "голый" класс не имеет родительских методов вообще. Уверен, что коллеги на портале, которые более опытные в текстовых языках, могут привести больше сравнений.
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby Vitekkz88 on 21 Nov 2017, 10:31

Kosist писал(а): Сегодня заказчик сказал, что программа должна общаться с контроллером по TCP/IP, а завтра - через ком порт. Сегодня в качестве мультиметра используется NI железо, завтра - железо от Agilent. А значит, разные протоколы, разные драйвера

Сборка проекта проводится с учетом изменившихся реалий и всё. Никаких заморочек с использованием классов. Работа с железом реализуется отдельным потоком. Если поменялся протокол, то его нужно реализовать и встроить в программу. Что вы на лету это будете делать, что это будет происходить по кейсу - аще разницы нет. Придётся перекомпилировать и ставить по новой.Поменяли железо - добавили блоки управления им и всё - дальше в бой. Поменяли интерфейс взаимодействия? Не беда - перекомпелируем под последовательный порт. А если надо, то сразу по всем сделаем. И всё это делается так же без проблем. Уверен, что у разработчиков одного и того же калибра потратится на всё это примерно одинаковое количество времени.
А как вы просимулируете отработку команд железом? Вы можете элементарно облажаться на один байт в команде и всё. С SCPI работали? Или условия тепличные с железками NI? :D А там хоть запрогоняйтесь. Конечно следует всё подготовить и т.д. - но это не долго по сравнению с отладкой в железе. И бОльшую сложность составляет проверка логики и алгоритмов, а не управление железкой. С этим, как раз более менее всё понятно. Можно эмулировать ответы от оборудования для проверки. Но повторюсь, вы не сможете отладить протокол работы с оборудованием без самого оборудования. А протоколы взаимодействия можно вынести в отдельные SubVI, если это список команд - то можно их по номерам разбирать и отправлять куда нужно.
Kosist писал(а): если Вам нужно в библиотеке Б использовать цепочку из виаек библиотеки А, например, так (в порядке вызова): VI1 - VI2 - VI3 и нужно изменить функционал VI2, как Вы поступите?

Всё верно, если участки кода предпологают изменение функционала чего либо - то я вынесу это в отдельный subVI. Не вижу смысла делать отдельные грабли с подменой на лету. Ни себе ни тому, кто потом сопровождать будет и ловить лулзы на этом.
За то, что можно обойтись без очереди для логированния ошибок - респект :D Но мне, например, и с очередью хорошо, любовь у нас уже давно.
Kosist писал(а)в трад. подходе больше "завязанность" на интерфейсы виаек, входа-выходы. А в случае классов Вы работаете с интерфейсами. И тогда замена функционала происходит менее болезненно.

В традиционном подходе делается бОльшая часть софта более-менее. Изменения касаются лишь некоторых частей программы, которые и без ООП нормально правятся.
Я знаю преимущества ООП, я умею это и практикую :crazy: Вопросов много, и будет время - сам разберусь с этим и определю степень ООП-шности Actor-а. Но переводить LabVIEW на эти рельсы ИМХО - себе дороже выйдет, тем более есть много ограничений. А применять повсеместно - тоже нет резона и особого смысла...только в каких-то супер-проектах или исключительных случаях. В целом можно программировать и не парить мозг, делая всё через subVI. А переопределить выходы SubVI для другого проекта - не проблема, тоже дел на 2 минуты. Пока не вижу профита всего этого именно для LV. Но не исключаю, ведь: "всё же от задачи зависит" :crazy:
LVOOP напоминает мне tree-контрол, если Вы понимаете о чем я :brows:
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby Kosist on 21 Nov 2017, 12:15

На вкус и цвет фломастера разные ))))
Насчет HAL Вы не правы, уж извините. Да, протокол железа Вы так не отладите. Но вот логику целой программы - легко. А это тоже важно. Плюс для меня также важна отладка уже готового exe, если вдруг проблемы. С плагином это легко - дело конфигурации; не нужно конфигурировать флаги, условия. Просто целиком "на лету" заменяется код, и все работает. И на переделку в случае грамотного ООП уйдет менее времени, нежели с просто сабвиайками.
Каждый делает так, как ему нравится, и если все получается и работает - то очень здорово.
AF - это все-таки фреймворк, а каждый использует ту архитектуру, которая ему по душе, и с которой ему комфортно.
Плюс ко всему, как Вы и писали, все зависит от проектов. От сложности, от объема, от повторяемости.
Vitekkz88 wrote:А переопределить выходы SubVI для другого проекта - не проблема, тоже дел на 2 минуты. Пока не вижу профита всего этого именно для LV.

Да есть же профит. У Вас будет две разные виайки. И виайки, которые будут вызывать эти подприборы, тоже будут разными - т.к. нужно будет передавать/принимать другой тип данных. А с ООП этой проблемы не будет, ибо все будет делаться через интерфейс - тот же тип данных. А это значит, что если нужно будет исправить баг в главной виайке (а баги есть всегда и везде), то Вы это сделаете в одном месте, а не в двух. И т.д., и т.п. Вы же работаете с ООП, понимаете о чем я говорю.
Но опять же, все это - дело привычки, дело подхода. Процедурный или объектный подход - вот и вся разница :wink:
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby Vitekkz88 on 21 Nov 2017, 12:40

Kosist писал(а): Насчет HAL Вы не правы, уж извините.

А в чем я не прав то? Я просто рассказал, как что происходит :D Протокол не отладить, можно так же накосячить и на симуляции ответов - как следствие накасячить в алгоритме обработки. Если кто-то лишает работы с железом, но требует настоятельно под него писать - ставьте перед фактом. Рано или поздно это произойдет. Прокатило раз-два, на третий обязательно будет косяк и поиск что не так именно в программе. Плавали, знаем. И дело не в том, что поменяли драйвер или поменяли интерфейс взаимодействия. Повторюсь - накидать программу без железа можно, но гарантировать её работоспособность - нет :D
Kosist писал(а): Да есть же профит.

Да есть-есть, я понимаю это! :crazy: Только он не повсеместный и не такой явный. Он есть, но только на определенном секторе задач и проектов. То есть я не могу взять LVOOP и писать на наём все проекты. Это просто нецелесообразно, это не разумно в конце концов, это больше лишних телодвижений. В то время как на Java я просто обязан делать всё через классы. А в С++ - не обязан, например, но карма не позволит делать всё в Си-шном стиле.
В этом и кроется основная мысль: LabVIEW не обязывает знать LVOOP для написания сколь-угодно сложного проекта(в данный момент). В то же самое время другие языки с ООП требуют использования того самого ООП, т.к. без него никак. Поэтому я так и сказал: если захочу софт с полноценным ООП - то буду использовать другие технологии. Это не должно оскорблять LabVIEW или вызывать негодования типа "Зря вы так". Нифига не зря, потому что LabVIEW позволяет мне сделать нормальный софт с годной читабельностью и сопровождением не требуя ООП как такового(полноценного или с какими-то костылями - не важно).
Но за экскурс по Actor-у спасибо :-)
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby Kosist on 21 Nov 2017, 18:51

Vitekkz88 wrote:Протокол не отладить, можно так же накосячить и на симуляции ответов - как следствие накасячить в алгоритме обработки.

Это понятно, накосячить можно в любом случае.
Vitekkz88 wrote:Если кто-то лишает работы с железом, но требует настоятельно под него писать - ставьте перед фактом.

Вы же знаете, что в идеальном мире все так бы и работало. Но в реале - само собой, нет )) То железо не пришло, то фикстура не готова, то тестируемое устройство полностью не работает. Но я же не хочу ждать, пока все будет на месте, чтобы прогнать программу, и посмотреть - пишутся ли логи, запускаются интерфейсы, и т.д.? Я например работаю с TestStand часто; и если мне нужно продебажить последовательность в целом без железа, то не буду же я скипить шаги? Интерфейса для симуляции хватит с головой. Если мне нужен триггер от цифровой карты, то я могу его легко просимулировать, не боясь ошибки с реальным железом (конечно, если под это железо уже есть работающие, ранее написанные либы).
Раньше я использовал кейс структуры, Conditional Disable структуры - тоже можно было тестировать. Но стоит забыть сделать активной одну из них - и все, нужно перебилдить екзе.
Я не говорю, что плагины или HALы спасают от всего, нет. Но как по мне, то с ними намного легче.
Это ведь как, скажем, с версиями софта. Кто-то использует SVN или GIT, а кто-то все по папочкам раскидывает с номерами-индексами. И цель будет достигнута, но пути совершенно разные.
Или тестирование модулей - кто-то пишет юнит-тесты; а кто-то вручную проклацывает, и вроде все работает.
Vitekkz88 wrote:Повторюсь - накидать программу без железа можно, но гарантировать её работоспособность - нет :D

Можно, если железо "знакомое" и "простое". Понятно, что если это будет какой-то спектральный анализатор, то просимулировать коммуникацию с ним, ответы от него будет тяжело, и не эффективно. Но "обвязку" вокруг него, другое железо "рядом" - почему бы и нет?
Vitekkz88 wrote:В этом и кроется основная мысль: LabVIEW не обязывает знать LVOOP для написания сколь-угодно сложного проекта(в данный момент).

Это да, это правда. LabVIEW - софт для инженеров, которым некогда изучать программирование, но нужно создавать программы под себя. И это классно, т.к. можно достигать нужной цели с минимумом усилий. Но стоит задуматься о архитектуре, повторном использовании, распространения, поддержки версий - и уже совсем другая история.
Как-то так :crazy:
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby Vitekkz88 on 22 Nov 2017, 06:53

Vitekkz88 писал(а):
Повторюсь - накидать программу без железа можно, но гарантировать её работоспособность - нет :D

Kosist писал(а): Можно, если железо "знакомое" и "простое". Понятно, что если это будет какой-то спектральный анализатор, то просимулировать коммуникацию с ним, ответы от него будет тяжело, и не эффективно.

Ну дк с простыми устройствами конечно(релюшки или платы сбора данных DAQ) - их легко симулировать. У меня, например, панорама устройств как раз из RF-сегмента, USB реле и аттенюаторы, платы ЦАП, АЦП. Вот залью щас пару фоток в тему "моё рабочее место" http://labviewportal.ru/viewtopic.php?f=92&t=1801&p=76837#p76837, оцените. И как б*!@#ь это всё симулировать? :D Это не DAQ настроить да мультиметром показания снимать - это всё я проходил и прекрасно представляю. Почему RF-сегмент не от NI - опустим.
Kosist писал(а): Я например работаю с TestStand часто; и если мне нужно продебажить последовательность в целом без железа, то не буду же я скипить шаги? Интерфейса для симуляции хватит с головой. Раньше я использовал кейс структуры, Conditional Disable структуры - тоже можно было тестировать. Но стоит забыть сделать активной одну из них - и все, нужно перебилдить екзе.

Вам достаточно посмотреть выходные пакеты с данными и всё(если обмен идёт по протоколу со сторонним оборудованием). Забывчивость? Не, не слышал. Всё четко с кейсами или в параллель в случае разных железок или интерфейсов. Ребилд - 5-10 минут, не? Или может по 4 часа собираться? :D
Kosist писал(а): Но стоит задуматься о архитектуре, повторном использовании, распространения, поддержки версий - и уже совсем другая история.

Повторное использование уместно, если проекты один в один под копирку идут либо с небольшими изменениями. Иначе нужно писать проект с нуля, с учетом всех ньюансов. Не я первый и не я последний, кто убеждён что лучший проект - это новый проект. Вряд ли вы возьмёте класс из RF и потащите его в проект для вибростенда.
Все тулкиты - это фреймворки LabVIEW-шные со своими методами. Поэтому когда Вы создаёте класс в проекте и планируете его дальше где-то использовать - то окиньте взглядом перспективы: "а будут ли такие проекты еще? А как это можно использовать или прикручивать в другие проекты? А есть ли смысл таскать этот класс из проекта в проект или создать новый?" В итоге Вы получите набор собственных классов, либо один собственный супер-класс(это нормально, что он будет огромным. Фреймворки для Enterprice-разработки например включают в себя десятки тысяч классов с кучей методов на все случаи жизни). За выигрыш по времени разработки просите у генерального доп.выходной. Я бы дал :crazy:
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Re: Actor Framework

Postby Kosist on 22 Nov 2017, 09:02

Vitekkz88 wrote:Забывчивость? Не, не слышал.

Давно человеческий фактор со счетов начали сбрасывать? И код без багов сразу пишете :crazy: ? Снимаю шляпу :thank: ))
Vitekkz88 wrote:Повторное использование уместно, если проекты один в один под копирку идут либо с небольшими изменениями. Иначе нужно писать проект с нуля, с учетом всех ньюансов.

Vitekkz88 wrote:Вряд ли вы возьмёте класс из RF и потащите его в проект для вибростенда.

Если у Вас монолитная архитектура - то да. А если модулярная - то нет. До определенного уровня какая разница, пишу я тест программу под авторадио, или под модуль управления кухонной вытяжки, если мне нужно будет и там, и там - мерять что-то мультиметром, управлять цифровыми линиями, анализировать дисплей камерой, писать логи, тест-отчеты, генерить сообщения юзеру, читать/писать с датабазы, общаться с устройством через ком-порт, и т.д.? Да, будет много разных модулей, но будут и одинаковые, или однотипные.
Какая разница, будет ли это хост-приложение для cRIO, или для лабораторного стенда для измерения вибрации, если и там, и там нужно будет отображать графики, вызывать окно настроек, вводить логины/пароли, переключать языки? Действия те же, а значит ядро будет одинаковое.
Если раз напишете плагин под CAN или LIN карту, то сможете на его основе создавать новые, под других производителей, под другие комманды. Ведь смысл останется тот же. Нужно будет устройство инициализировать, посылать пакеты, отслеживать сигналы; опять же писать логи, и т.д. Смысл тот же, программный интерфейс - тот же; только драйвера другие.
Vitekkz88 wrote:Не я первый и не я последний, кто убеждён что лучший проект - это новый проект.

Значит, все говорят о code reusability, но Вы предпочитаете хардкор. Ваш выбор ))) А я верю в лучшее, и мне лень все создавать сначала. Вот и пытаюсь заморачиваться.
Мы делили апельсин - много наших полегло...
User avatar
Kosist
leader
leader
 
Posts: 783
Joined: 21 Feb 2011, 23:44
Location: СумГУ
Medals: 2
Activity (1) Gold (1)
LabVIEW Version: 2013-2017
Karma: 236
CLAD I/O VIP students

Re: Actor Framework

Postby Vitekkz88 on 22 Nov 2017, 10:38

Kosist, разумеется модульность используется, но в виде SubVI . Но в целом проект создаётся новый. Ошибок делаю мало по части забыть убрать дизейбл или кейс. В мире лабвью это пока разговоры и частичный переход именно на ооп. Повторное использование существует давно и успешно всеми применяется , но не через призму лабвьюшного ооп.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
leader
leader
 
Posts: 945
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 258
hardware I/O VIP

Previous

Return to Модели программирования

Who is online

Users browsing this forum: No registered users and 2 guests

cron