#1
|
|||
|
|||
![]() Применение SWITCH-технологии при программировании сложной логики в LabVIEW (на примере АСУ ТП)
http://is.ifmo.ru/progeny/_vavilov2.pdf.zip |
#2
|
|||
|
|||
![]() клип о применении SWITCH-технологии при программировании в LabVIEW (на примере АСУ ТП)
http://slil.ru/22462244 |
#3
|
||||
|
||||
![]() Очень интересно, но долго разбираться. Помоему существует State Diagramm Toolkit, который переделывает графы переходов в LabVIEW Source Code.
__________________
LabVIEW Portal Последний раз редактировалось Тотолотто, 17.11.2005 в 15:23. |
#4
|
||||
|
||||
![]() Цитата:
Конечные автоматы -- вообще рекомендуемая структура сложных виай в LabVIEW, есть даже стандартный Design Pattern, и упомянутый Тотолотто State Diagramm Toolkit. Еще интересно, как соотносится представленная разработка с коммерческим продуктом LabHSM [http://labhsm.com/]. Не изобрели ли авторы велосипед? ![]() Последний раз редактировалось step, 18.11.2005 в 00:14. |
#5
|
|||
|
|||
![]() Цитата:
Приведен пример применения атоматного подхода. И хотелось бы найти единомышленников. Я являюсь начальником группы программистов АСУ. А исполнители (рядовые программисты) бывают разные. Необходимо же совершенно точно быть уверенным, что в любом случае логическая часть проекта будет реализована. Я уверен, что ошибки логики алгоритма нужно анализировать по рисунку, а не в программе. Приведенная технология позволяет это сделать без проблем. Цитата:
Цитата:
То есть по существу схема алгоритма (автомата) ВРУЧНУЮ переносится в LabVIEW, причем в своеобразном виде. Во-первых, этот вид абсолютно не нагляден. Во-вторых, зачем городить промежуточное представление? Если потребуется изменяется алгоритм, то нужно будет изменять не только рисунок (для документации), но и опять изменять промежуточное представление. По-моему, это гарантирует ошибки именно при наборе, программировании. И потом где гарантия, что код логики будет точно соответствовать алгоритму? |
#6
|
|||
|
|||
![]() Цитата:
Ну, считайте меня одним из них! ![]() Как автор LabHSM, я очень рад, что мои соотечественники - "правильные пацаны", пардон, программеры ![]() Цитата:
LabHSM позволяет ассоциировать действия как с переходами между состояниями по (приоритезированным!) событиям, так и со входом и выходом из состояния. Главное же, что LabHSM реализует вложенные состояния с наследованием переходов, что неимоверно сокращает описание поведения автомата по сравнению с "плоской" моделью автомата Мура, до сих пор представляемого NI (и SDK) как единственно возможная машина состояний SDK сослужил хорошую службу LabVIEW сообществу однако, выдав технологию X-nodes (http://xnodes.lavausergroup.org) ![]() Цитата:
Я в этом редакторе и создаю и меняю схему автомата. И тут же могу проверить как это работает, даже когда ещё не всю схему реализовал и ещё даже не осознаю, что ещё может понадобиться. Это соответствует принципам "гибкого" программирования, программирования методом "последовательных прототипов" и т.п. Согласен, графическое представление более наглядно. Харел и разработал statecharts как визуальное средство, хотя он признаёт, что они по сути "AND/OR trees" прямо там, в своей знаменитой статье Statecharts: A Visual Formalism for Complex Systems ( http://www.quantum-leaps.com/resources/Harel87.pdf ) Да, круто было бы сделать для LabHSM графический редактор как в SDK, вместо Tree Сontrol. Также, очень хотел бы посмотреть на транслятор диаграмм состояний и переходов из Visio в какой-нибудь текст (XML?) Есть желающие помочь? Так же как и у вас, основная идея LabHSM - отделение информации о поведении автомата (в каком состоянии, если произойдет какое событие, какие действия надо совершить и перейти в какое следующее состояние), от собственно LabVIEW кода. Это позволяет иметь одну и ту же структуру собственно кода независимо от его назначения и сложности. Меняются только манипулируемые данные и число и содержание действий над ними. Это сильно повышает модифицируемость: Когда например, вы понимаете, что когда событие А случается в состоянии Б, нужно прогнать и действие Г тоже (вдобавок к тому, что уже назначено), это можно сделать, не меняя вообще ничего на BD, просто добавив это действие в список для данного перехода. Главное, чего не хватает в LabHSM это не графический редактор, однако, а реализации состояний типа И (AND states). Без них трудно компактно описывать слабо связанные пространства состояний в одном автомате. Классический пример: светофор может быть красным, жёлтым или зелёным, И работать либо от сети номер 1 либо от сети номер 2 либо от резервной батареи. Без состояний типа И нам или придётся создавать 9 состояний вместо 6, либо разбивать объект на две подсистемы и надстройку, представляющую светофор как единый объект для других объектов в системе. Добавьте ещё какой-нибудь один бинарный флаг, от которого зависит поведение и общее число состояний (в худшем случае) может ещё раз удвоиться (state space explosion). Однако, эта проблема облегчается в LabHSM наличием возможности создания вложенных состояний, которые могут наследовать поведение от состояний в которые они вложены, и переходов типа To History. Пища для раздумий: всё это (создание автоматов с помощью Loop и Case) было бы не нужно, если бы при сохранении параллельного и независимого движения множественных токенов данных LabVIEW позволяло всего лишь две дополнительные вещи на блок-диаграмме: неявное зацикливание и узел, в котором данные выводились только на один из выходов в зависимости от значения на входе. То есть, если бы LabVIEW позволяла напрямую реализовать сети Петри. Ведь, если подумать, структуры Case и Loop - очень чужеродные вещи, наложенные поверх графа! Но приходится работать с LabVIEW такой, какая она есть, вот мы и "городим". ![]() Станислав Румега NI Certified LabVIEW Architect |
#7
|
|||||
|
|||||
![]() Станислав, огромное спасибо за обстоятельный комментарий и информацию. Приятно когда собеседник разбирается в предмете разговора, иногда может даже лучше чем ты сам. Хотелось бы подискутировать по ряду моментов.
Скажу сразу - я не квалифицированный программист, поэтому могу ошибаться в терминологии и чего-то не понять из Ваших объяснений. И еще - предлагаю говорить только об управлении, т.е. не касаться верхнего уровня (интерфейса с пользователем). SWITCH-технология и ООП - это не моя тема. Одно представляю точно - когда пишешь программу сам и когда руководишь коллективом разных по квалификации людей - это "две большие разницы". Поэтому и отрабатываю технологию проектирования как можно простую. Предшественником работы "LabVIEW и SWITCH-технология" является http://is.ifmo.ru/progeny/_metod065.pdf (Программируемые логические контроллеры SIMATIC S7-200 (SIEMENS). Методика алгоритмизации и программирования задач логического управления). Причем слова "SIMATIC S7-200 (SIEMENS)" можно смело выкинуть, так как для предлагаемого применения автоматов АБСОЛЮТНО НЕ ВАЖНО (акцентирую) ни среда разработки ни среда исполнения. Главное - есть схема алгоритма (для анализа и документации) и есть возможность простой конвертации для исполнения. Все. Цитата:
Цитата:
Со мной тоже трудятся один-два человека. Цитата:
Цитата:
Цитата:
![]() |
#8
|
||||
|
||||
![]() Я рад, что на нашем форуме появились серьезные профессиональные обсуждения!
![]() По поводу представления логики в виде диаграмм. При печати на А4 _vavilov2.pdf текст многих схем будут просто нечитаемы. Если растянуть схему на несколько страниц -- возникнет полная путаница в стрелках. Так что использование диаграмм такого размера в документации под вопросом... Еще вопрос к Станиславу: цитата с Вашего сайта Цитата:
![]() Переваривая Цитата:
|
#9
|
|||||
|
|||||
![]() Цитата:
Цитата:
Цитата:
А теперь посмотрим. В классическом ООП чтобы объект "собака" "гавкнул", нужно чтобы внешний (по отношению к объекту "собака") код вызвал метод "bark". Очень "реалистичное" моделирование! ![]() Цитата:
Вы хотите сказать, что вы настолько хорошо прорабатываете граф переходов, что потом транслируете его в код только один раз? Если нет, то вы тоже "сразу программируете", причём "итеративно". Создание графов переходов это тоже программирование, только на более высоком уровне абстракции. Сами же говорите "изоморфизм". Цитата:
![]() |
#10
|
|||
|
|||
![]() Цитата:
|
#11
|
|||
|
|||
![]() Мне ещё предстоит почитать труды господ Шалыто и Туккеля, но должен заметить, что при беглом просмотре работ опубликованных на http://www.softcraft.ru/auto.shtml вызвало некоторое недоумение отсутствие в списках литературы ссылок на Дэвида Харела (http://www.wisdom.weizmann.ac.il/~dharel/) и его основополагающую работу в этой области: Harel, David. 1987. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming (no. 8), 231-274.
(http://www.wisdom.weizmann.ac.il/~dh...tatecharts.pdf) ![]() http://www.quantum-leaps.com Станислав |
#12
|
|||
|
|||
![]() Цитата:
|
#13
|
|||
|
|||
![]() Цитата:
Все-таки представьте вид алгоритмов при другом представлении... Могу сказать еще больше - пока никто из пользующихся технологией не обращал особого внимание на размер рисунка графа. |
#14
|
|||
|
|||
![]() Цитата:
Цитата:
![]() |
#15
|
||||
|
||||
![]() Здравствуйте!
Очень интересно. Пробовал вникнуть в тему, но к сожалению в институте пропустил эту тему мимо ушей. Прочитал большинство статей и даже Харрела на английском. Всё таки трудно обычному программисту создавать проект по принципу State Machine. Не хватает обьективности. Но очень хотелось бы научиться. Как я понял, SWITCH-Technology - проект более менее открытый, но инструкций по использованию так и не нашёл. То что написано в PDF - общая информация, Source Code не видно и проект слишком специфический и трудоёмкий. Не хотелось бы показаться тупым, но приходится просить, нет ли у автора статьи "_vavilov2.pdf" информации для людей хотящих заняться этой темой, но начинающих. В институте мы проходили петри-сети, FSM, STEP 7, и всё таки из всей статьи я смог только выудить, что большие проекты можно или даже нужно создавать с помощью State Charts, но не как это сделать. Конкретные вопросы: 1. В каких случаях лучше применять FSM, а в каких обычный способ программирования (кроме избитых примеров: электронные часы, стиральная машина, лифт, монетный автомат и т.п.)? Рационально ли использовать такой метод, при программировании GUI для коммуникации со сложными приборами и их управлением? 2. Можно ли получить конкретное объяснение (шаг-за-шагом) как пользоватся технологией SWITCH или другой похожей некомерческой технологией? 3. Где можно найти хорошую, но бесплатную информацию, по использованию FSM конкретно в LABVIEW (рус, нем или англ)? В общем интерес есть, а конкретной информации нет. Как только дело касается практики все, переходят на коммерческие отношения. Извините за русский и возможную грубость, но это всё таки форум, высказываться можно. Всем спасибо. ![]()
__________________
LabVIEW Portal |
#16
|
|||
|
|||
![]() Цитата:
Только прошу заметить, что в моих работах описывается как ПРИМЕНЯТЬ SWITCH-технологию. И именно это. Собственно сама технология или автоматное программирование с программной точки зрения - это применение определенной (и весьма эффективной) конструкции, инструкции при программировании алгоритмов, описанных графами переходов. Есть несколько методик как применять. Я "придумал" разделение автоматов на базовые и технологические и описал взаимодействие между ними. Кто-то применяет SWITCH-технологию по-другому (статьи есть на http://is.ifmo.ru/). |
#17
|
||||
|
||||
![]() Спасибо,
прочитал ещё раз Ваши обе статьи повнимателней. Так же нашёл конвертер Visio2Switch, к сожалению пока не исробовал из за отсутствия пакета Visio. Всё таки создаётся впечатление, что использование SWITCH технологии по вашему методу (или вообще) занимает нааамного больше времени, чем ООП, т.е. привычный метод программирования. Проект описаный Вами смотря на тех. описание задачи относительно громоздкий и очень ответственный, но разработка 125-ти !!! автоматов, не слишком ли это? А ещё я не понимаю зачем использовался пакет ЛабВью, если конвертер выдаёт Сишный код? Неужели только как графический набор красивых индикаторов? Ведь для этого есть Measurement Studio. И всё таки я бы очень хотел так же как и Вы щёлкать эти автоматы как орехи. Мне кстати очень помогла разобраться в составлении автоматов статья Дугласа, что не скажешь о других статьях. У Харела только теория (но она так и называется), а у Вас в статье вид на проект сверху и издалека, я бы пожелал разобрать один средненький автоматик по частям и подробно описать его, так же мне не хватает последнего шага, где все автоматы сливаются в одну программу. В статье в принципе есть одна блок-диаграмма, но она объясняется не очень подробно. Есть ещё два мелочных вопроса: Не смог разобраться с нумерацией состояний в Ваших автоматах (10, 66, 99). Не подскажите ли где это описано? Что касается диалоговых окон в Вашем проекте, то как я понял они не модальные, ведь в противном случае они бы не вписались в принцип работы вашей программы. Может быть можно что нибудь придумать (например раздать им приоритеты и показывать их по очереди, а не все сразу). А если проект был бы ещё сложнее, то на экран вышло бы например 40 диалогов. Огромное спасибо за Вашу идею, я надеюсь она поможет мне в будущем эффективнее программировать. ![]()
__________________
LabVIEW Portal |
#18
|
||||
|
||||
![]() Цитата:
__________________
LabVIEW Portal |
#19
|
||||||
|
||||||
![]() Цитата:
Все-таки прочитали статьи невнимательно. Я пользуюсь своим конвертором для того чтобы потом вставить текст в Formula Node пакета LabVIEW (Formula Node "понимает" синтаксис Си), а конвертер Visio2Switch генерит текст целой программы на Си и я им не пользуюсь - зачем?. Цитата:
Цитата:
Не очень понял критерий выбора программного средства - LabVIEW или Measurement Studio... Если заводить разговор о выборе, то это будет отдельная большая ветка форума. Делайте где Вам нравиться - какие проблемы? Метод работает везде. Цитата:
Базовые и технологические выполняются параллельно. Приводить это в графическом коде на языке G - это не реально. Цитата:
Нумерация вообще-то предполагалась вольная. А а конкретно здесь просто сильно отличными от других цифрами обозначены особые состояния - например, 10 - неустойчивое состояние, зависящее от времени, 66 - неисправность, 99 - начальное или конечное состояние и т.д. Это не принципиально. Цитата:
Как выводить на экран диалоги - забота программиста - придумайте свой способ, главное чтобы не прерывалась нормальная работа установки и одновременно с этим оператор должен быть своевременно информирован о неисправности. Естественно, когда окон на экране много - это мягко сказать "плохо". Но подразумевалось, что диалоги будут вылезать только когда нужно по нормальному ходу работы установки (и их общее количество на экране будет небольшим, 1-4). А если случается ненормальная ситуация, то оператор вообще-то должен реагировать сразу... |
#20
|
||||
|
||||
![]() Цитата:
Цитата:
Но ведь если Formula Node понимает синтакс Си, то можно объединить все, сгенерированые с помощью Visio2Switch файлы, в один и запихать в Formula Node.
__________________
LabVIEW Portal |
![]() |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|
|
![]() |
||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
возможности LabView | Maksim | Программирование в LabVIEW | 7 | 21.11.2011 21:46 |
LabVIEW и плата KEITHLEY KPCI-3132 | ECS-Engineer | Программирование в LabVIEW | 1 | 18.03.2011 09:07 |
Работа с портами в LabView | Avel | Программирование в LabVIEW | 6 | 06.02.2009 14:37 |
Ежегодная олимпиада по программированию в LabVIEW – 2008 | East_girl | Программирование в LabVIEW | 12 | 17.04.2008 14:29 |
Работа: программист на LabVIEW в Москве | Oleg | Свободный форум | 4 | 25.08.2006 17:28 |