LabVIEW и SWITCH-технология

[WaW]

Применение SWITCH-технологии при программировании сложной логики в LabVIEW (на примере АСУ ТП)

http://is.ifmo.ru/progeny/_vavilov2.pdf.zip

[WaW]

клип о применении SWITCH-технологии при программировании в LabVIEW (на примере АСУ ТП)
http://slil.ru/22462244

[Тотолотто]

Очень интересно, но долго разбираться. Помоему существует State Diagramm Toolkit, который переделывает графы переходов в LabVIEW Source Code.

[step]

Сообщение от WaW

Применение SWITCH-технологии при программировании сложной логики в LabVIEW (на примере АСУ ТП)

Интересная работа, только создается впечатление о некой революционности SWITCH-технологии(R). В действительности, насколько я понял, это развитие (особенно в области сложных практических применений) теории конечных автоматов (Finite State Machines) сорокалетней давности.

Конечные автоматы -- вообще рекомендуемая структура сложных виай в LabVIEW, есть даже стандартный Design Pattern, и упомянутый Тотолотто State Diagramm Toolkit.

Еще интересно, как соотносится представленная разработка с коммерческим продуктом LabHSM [http://labhsm.com/]. Не изобрели ли авторы велосипед? Что на это скажет WaW?

[WaW]

Сообщение от step

Интересная работа, только создается впечатление о некой революционности SWITCH-технологии(R). В действительности, насколько я понял, это развитие (особенно в области сложных практических применений) теории конечных автоматов (Finite State Machines) сорокалетней давности.

Никто не претендует на революционность (по крайней мере я).
Приведен пример применения атоматного подхода.
И хотелось бы найти единомышленников. Я являюсь начальником группы программистов АСУ. А исполнители (рядовые программисты) бывают разные. Необходимо же совершенно точно быть уверенным, что в любом случае логическая часть проекта будет реализована. Я уверен, что ошибки логики алгоритма нужно анализировать по рисунку, а не в программе. Приведенная технология позволяет это сделать без проблем.

Сообщение от step

Конечные автоматы -- вообще рекомендуемая структура сложных виай в LabVIEW, есть даже стандартный Design Pattern, и упомянутый Тотолотто State Diagramm Toolkit.

Не подскажете где скачать?

Сообщение от step

Еще интересно, как соотносится представленная разработка с коммерческим продуктом LabHSM [http://labhsm.com/]. Не изобрели ли авторы велосипед? Что на это скажет WaW?

Насчет LabHSM - как я понял существует только ручной набор состояний, событий в специальном редакторе и последующая интеграция в диаграмму LabVIEW.
То есть по существу схема алгоритма (автомата) ВРУЧНУЮ переносится в LabVIEW, причем в своеобразном виде.
Во-первых, этот вид абсолютно не нагляден.
Во-вторых, зачем городить промежуточное представление? Если потребуется изменяется алгоритм, то нужно будет изменять не только рисунок (для документации), но и опять изменять промежуточное представление. По-моему, это гарантирует ошибки именно при наборе, программировании. И потом где гарантия, что код логики будет точно соответствовать алгоритму?

[HViewLabs]

Сообщение от WaW

Никто не претендует на революционность (по крайней мере я).
Приведен пример применения атоматного подхода.
И хотелось бы найти единомышленников.

Ну, считайте меня одним из них!

Как автор LabHSM, я очень рад, что мои соотечественники - "правильные пацаны", пардон, программеры , в том смысле, что стараются применять "правильные" методы.

Сообщение от WaW

Не подскажете где скачать?

За продукт с очень ограниченными возможностями (несмотря на графический редактор и полный доступ его создателей ко всей мощи "секретных" функций LabVIEW Scripting), называемый State Diagram Kit, NI требует $1000. Так что, просто так вы его не скачаете. SDK, не поддерживает вложенные состояния, зато создаёт глубоко вложенный код. Более того, вообще, то что NI подаёт как State Machine (и соответственно, то, что генерит SDK), это только одна из разновидностей, так называемый автомат Мура, который позволяет ассоциировать действия только со входом в состояние, а не с переходом (как автомат Мили). Одна и та же система потребует большего числа состояний для описания с помощью автомата Мура, чем с помощью автомата Мили.

LabHSM позволяет ассоциировать действия как с переходами между состояниями по (приоритезированным!) событиям, так и со входом и выходом из состояния. Главное же, что LabHSM реализует вложенные состояния с наследованием переходов, что неимоверно сокращает описание поведения автомата по сравнению с "плоской" моделью автомата Мура, до сих пор представляемого NI (и SDK) как единственно возможная машина состояний

SDK сослужил хорошую службу LabVIEW сообществу однако, выдав технологию X-nodes (http://xnodes.lavausergroup.org)

Сообщение от WaW

Насчет LabHSM - как я понял существует только ручной набор состояний, событий в специальном редакторе и последующая интеграция в диаграмму LabVIEW.
То есть по существу схема алгоритма (автомата) ВРУЧНУЮ переносится в LabVIEW, причем в своеобразном виде.
Во-первых, этот вид абсолютно не нагляден.
Во-вторых, зачем городить промежуточное представление? Если потребуется изменяется алгоритм, то нужно будет изменять не только рисунок (для документации), но и опять изменять промежуточное представление. По-моему, это гарантирует ошибки именно при наборе, программировании. И потом где гарантия, что код логики будет точно соответствовать алгоритму?

Да не переношу я ничего. Отдельную детальную документацию поведения всех автоматов в программе (постоянно меняющегося в процессе разработки - это реальность!) делать (и постоянно модифицировать) - непозволительная роскошь для маленьких проектов делаемых на заказ одним-двумя программистами в маленькой консалтинговой компании в штатах.

Я в этом редакторе и создаю и меняю схему автомата. И тут же могу проверить как это работает, даже когда ещё не всю схему реализовал и ещё даже не осознаю, что ещё может понадобиться. Это соответствует принципам "гибкого" программирования, программирования методом "последовательных прототипов" и т.п. Согласен, графическое представление более наглядно. Харел и разработал 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

[WaW]

Станислав, огромное спасибо за обстоятельный комментарий и информацию. Приятно когда собеседник разбирается в предмете разговора, иногда может даже лучше чем ты сам. Хотелось бы подискутировать по ряду моментов.
Скажу сразу - я не квалифицированный программист, поэтому могу ошибаться в терминологии и чего-то не понять из Ваших объяснений. И еще - предлагаю говорить только об управлении, т.е. не касаться верхнего уровня (интерфейса с пользователем). SWITCH-технология и ООП - это не моя тема.
Одно представляю точно - когда пишешь программу сам и когда руководишь коллективом разных по квалификации людей - это "две большие разницы". Поэтому и отрабатываю технологию проектирования как можно простую. Предшественником работы "LabVIEW и SWITCH-технология" является http://is.ifmo.ru/progeny/_metod065.pdf (Программируемые логические контроллеры SIMATIC S7-200 (SIEMENS). Методика алгоритмизации и программирования задач логического управления). Причем слова "SIMATIC S7-200 (SIEMENS)" можно смело выкинуть, так как для предлагаемого применения автоматов АБСОЛЮТНО НЕ ВАЖНО (акцентирую) ни среда разработки ни среда исполнения. Главное - есть схема алгоритма (для анализа и документации) и есть возможность простой конвертации для исполнения. Все.

Сообщение от HViewLabs

Да не переношу я ничего.

Все-таки наверняка первоначально схему Вы создаете на бумаге (в рисунке).

Сообщение от HViewLabs

Отдельную детальную документацию поведения всех автоматов в программе (постоянно меняющегося в процессе разработки - это реальность!) делать (и постоянно модифицировать) - непозволительная роскошь для маленьких проектов делаемых на заказ одним-двумя программистами в маленькой консалтинговой компании в штатах.

Схема алгоритма и является документацией. Заказчику чаще всего по барабану как именно реализована логика. Содержание документации МатОбеспечения прежде всего нужна разработчику (извините, постоянно рассматриваю процесс проектирования с точки зрения руководителя) и прежде всего для анализа (до тестирования и при тестировании).
Со мной тоже трудятся один-два человека.

Сообщение от HViewLabs

Я в этом редакторе и создаю и меняю схему автомата. И тут же могу проверить как это работает, даже когда ещё не всю схему реализовал и ещё даже не осознаю, что ещё может понадобиться. Это соответствует принципам "гибкого" программирования, программирования методом "последовательных прототипов" и т.п.

Вот сейчас понятно в чем разница в подходах - я рассматриваю схему алгоритма как основу для программы (или даже как готовую часть программы), а Вы сразу программируете ("не зная что еще может понадобиться", цитата). А как же анализ? В техзадании чаще всего многое не учтено, поэтому когда начинаешь создавать схему алгоритмов (в рисунке) легко определяешь узкие места, не описанные Заказчиком и согласовываешь их еще до программирования.

Сообщение от HViewLabs

круто было бы сделать для LabHSM графический редактор как в SDK, вместо Tree Сontrol.

Это необходимо.

Сообщение от HViewLabs

Также, очень хотел бы посмотреть на транслятор диаграмм состояний и переходов из Visio в какой-нибудь текст (XML?) Есть желающие помочь?

А в чем сложность? Я же как-то умудрился получить текст... с помощью конвертора, сделанного в LabVIEW...

[step]

Я рад, что на нашем форуме появились серьезные профессиональные обсуждения!

По поводу представления логики в виде диаграмм. При печати на А4 _vavilov2.pdf текст многих схем будут просто нечитаемы. Если растянуть схему на несколько страниц -- возникнет полная путаница в стрелках. Так что использование диаграмм такого размера в документации под вопросом...

Еще вопрос к Станиславу: цитата с Вашего сайта

Despite statecharts were developed as a graphical formalism, the state structure of an HSM is just a tree, so it can be suitably depicted with just a tree control.

Можно ли в этом дереве отображать всю информацию об автоматах (только в дереве, без дополнительных окон)? Если да, это дерево в какой-то мере может служить альтернативой диаграмме в документации. Мне представляется, что оно должно напоминать тех. задание в _vavilov2.pdf .

Переваривая

пищу для раздумий

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

[HViewLabs]

Сообщение от WaW

Станислав, огромное спасибо за обстоятельный комментарий и информацию.

Пожалуйста, Константин Валерьевич!

Сообщение от WaW

Скажу сразу - я не квалифицированный программист,

Я тоже! Я закончил физфак Ростовского университета в 1991 году, а в 2000 - мастерскую опять же по физике Western Michigan University. Вот же моё резюме, прямо там, на сайте LabHSM (http://labhsm.com/resume)

Сообщение от WaW

SWITCH-технология и ООП - это не моя тема.

Да не открещивайтесь вы так уж сразу! Идея-то не так уж сложна. В чём содержание традиционного (пассивного) ООП в нескольких предложениях? Программа при исполнении оперирует объектами. Объект состоит из 1)данных, 2)методов(действий, операций) над этими данными. Объекты создаются во время исполнения с шаблонов их описывающих (классов). При создании классов можно ссылаться на описание другого(их) классов (наследование), чтобы не повторяться в описании каких-то данных и методов. ВСЁ!

А теперь посмотрим. В классическом ООП чтобы объект "собака" "гавкнул", нужно чтобы внешний (по отношению к объекту "собака") код вызвал метод "bark". Очень "реалистичное" моделирование! Разве не естественнее модель в которой собака гавкает (прогоняет метод(ы)/действие(я)), когда она, например, увидела постороннего (реакция на событие (внешнее сообщение,воздействие)), если она конечно не спит в этот момент (реакция зависит не только от события, но и от состояния)? То есть объект/класс должен содержать не только данные и методы, но и информацию о ПОВЕДЕНИИ (дерево состояний, списки действий, событий и переходов) и соответствующий (вспомогательный и в принципе один и тот же для любых объектов) код его реализующий.

Сообщение от WaW

Вот сейчас понятно в чем разница в подходах - я рассматриваю схему алгоритма как основу для программы (или даже как готовую часть программы), а Вы сразу программируете ("не зная что еще может понадобиться", цитата). А как же анализ? В техзадании чаще всего многое не учтено, поэтому когда начинаешь создавать схему алгоритмов (в рисунке) легко определяешь узкие места, не описанные Заказчиком и согласовываешь их еще до программирования.

Это есть одна из основополагающих идей - объединить проектирование с кодированием (автоматизировать кодирование логики/поведения автомата). Вы же то же самое по сути делаете! Просто когда вы начинаете добавлять состояния и переходы на граф, я их добавляю в своём редакторе. Ну, лучше, лучше это делать графически - согласен, хотя сразу возникает проблема оптимзации размещения и аннотации графических элементов так, чтобы это читалось. Что, если, например, два перехода проходящие рядом оба имеют длинные списки действий ассоциированных с ними? Где лепить эти списки?
Вы хотите сказать, что вы настолько хорошо прорабатываете граф переходов, что потом транслируете его в код только один раз? Если нет, то вы тоже "сразу программируете", причём "итеративно". Создание графов переходов это тоже программирование, только на более высоком уровне абстракции. Сами же говорите "изоморфизм".

Сообщение от WaW

А в чем сложность? Я же как-то умудрился получить текст... с помощью конвертора, сделанного в LabVIEW...

Ну не все же такие гении! Я же вас не прошу подарить мне конвертер. Просто я буду признателен, если вы поможете сэкономить мне время и подскажете, где взять описание структуры и, желательно, пример (пусть даже на C, а не LabVIEW), как разбирать файлы VISIO. Или мне господина Головешина (http://www.geocities.com/goloveshin/v2s_rus.htm). спрашивать?

[HViewLabs]

Сообщение от step

Еще вопрос к Станиславу: Можно ли в этом дереве отображать всю информацию об автоматах (только в дереве, без дополнительных окон)? Если да, это дерево в какой-то мере может служить альтернативой диаграмме в документации. Мне представляется, что оно должно напоминать тех. задание в _vavilov2.pdf .

В самом то дереве (структуре данных, которую вы используете для описания) можете делать что хотите, конечно. Но вот конкретный Tree Control в LabVIEW 7 (который я вынужден был использовать для представления на FP, чтобы остаться в рамках только LabVIEW 7), этого не позволяет.

[HViewLabs]

Мне ещё предстоит почитать труды господ Шалыто и Туккеля, но должен заметить, что при беглом просмотре работ опубликованных на 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) . Я могу допустить, что эти уважаемые господа не читали работ написанных по-английски на эту тему, но с трудом могу представить, что они не слышали про UML, а уж любая книга по UML просто обязана упоминать Харела при объяснении statecharts! Другой классик - Даглас (Douglass, Bruce Powel). Хотелось также бы настоятельно порекомендовать всем интересующимся замечательную книгу (с русскими матрёшками на обложке!) Samek, Miro. 2002. Practical Statecharts in C/C++: Quantum Programming for Embedded Systems. CMP Books. Сайт автора со множеством информации и ресурсов по теме:
http://www.quantum-leaps.com

Станислав

[WaW]

Сообщение от HViewLabs

с трудом могу представить, что они не слышали про UML

Зайдите на сайт http://is.ifmo.ru/

[WaW]

Сообщение от step

При печати на А4 _vavilov2.pdf текст многих схем будут просто нечитаемы. Если растянуть схему на несколько страниц -- возникнет полная путаница в стрелках. Так что использование диаграмм такого размера в документации под вопросом...

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

[WaW]

Сообщение от HViewLabs

Вы хотите сказать, что вы настолько хорошо прорабатываете граф переходов, что потом транслируете его в код только один раз? Если нет, то вы тоже "сразу программируете", причём "итеративно". Создание графов переходов это тоже программирование, только на более высоком уровне абстракции. Сами же говорите "изоморфизм".?

А какая разница сколько раз транслируется код? ИСПРАВЛЯЕТСЯ РИСУНОК (причем понятный и не программисту) и соответственно, документация. Трансляция занимает секунды.

Сообщение от HViewLabs

Ну не все же такие гении! Я же вас не прошу подарить мне конвертер. Просто я буду признателен, если вы поможете сэкономить мне время и подскажете, где взять описание структуры и, желательно, пример (пусть даже на C, а не LabVIEW

Не надо обзываться "гением" По поводу описания структуры - не совсем понял о чем разговор, вероятно об программном интерфейсе автоматизации Visio. Честно говоря не знаю как это описывать (да еще так давно в 2003 году это делал, что просто не помню, надо код в LabVIEW смотреть, а на Си кстати ничего нет, не умею я Сикать). Насколько помню сложность не в доступе к OLE объектам, а в логике обработки полученной информации - группировке, сортировке, формирование текста определенной структуры и т.д. Может что-то понятно будет из http://is.ifmo.ru/progeny/_metod065.pdf? Там в Приложении есть принципы конвертации.

[Тотолотто]

Здравствуйте!

Очень интересно. Пробовал вникнуть в тему, но к сожалению в институте пропустил эту тему мимо ушей. Прочитал большинство статей и даже Харрела на английском. Всё таки трудно обычному программисту создавать проект по принципу State Machine. Не хватает обьективности. Но очень хотелось бы научиться.
Как я понял, SWITCH-Technology - проект более менее открытый, но инструкций по использованию так и не нашёл. То что написано в PDF - общая информация, Source Code не видно и проект слишком специфический и трудоёмкий. Не хотелось бы показаться тупым, но приходится просить, нет ли у автора статьи "_vavilov2.pdf" информации для людей хотящих заняться этой темой, но начинающих.
В институте мы проходили петри-сети, FSM, STEP 7, и всё таки из всей статьи я смог только выудить, что большие проекты можно или даже нужно создавать с помощью State Charts, но не как это сделать.

Конкретные вопросы:

1. В каких случаях лучше применять FSM, а в каких обычный способ программирования (кроме избитых примеров: электронные часы, стиральная машина, лифт, монетный автомат и т.п.)? Рационально ли использовать такой метод, при программировании GUI для коммуникации со сложными приборами и их управлением?

2. Можно ли получить конкретное объяснение (шаг-за-шагом) как пользоватся технологией SWITCH или другой похожей некомерческой технологией?

3. Где можно найти хорошую, но бесплатную информацию, по использованию FSM конкретно в LABVIEW (рус, нем или англ)?

В общем интерес есть, а конкретной информации нет. Как только дело касается практики все, переходят на коммерческие отношения.


Извините за русский и возможную грубость, но это всё таки форум, высказываться можно.

Всем спасибо.

[WaW]

Сообщение от Тотолотто

Как я понял, SWITCH-Technology - проект более менее открытый, но инструкций по использованию так и не нашёл. То что написано в PDF - общая информация, Source Code не видно и проект слишком специфический и трудоёмкий. Не хотелось бы показаться тупым, но приходится просить, нет ли у автора статьи "_vavilov2.pdf" информации для людей хотящих заняться этой темой, но начинающих.

Конкретные вопросы:

...2. Можно ли получить конкретное объяснение (шаг-за-шагом) как пользоватся технологией SWITCH или другой похожей некомерческой технологией?

Почитайте http://is.ifmo.ru/progeny/_metod065.pdf . Там самые азы.
Только прошу заметить, что в моих работах описывается как ПРИМЕНЯТЬ SWITCH-технологию. И именно это.
Собственно сама технология или автоматное программирование с программной точки зрения - это применение определенной (и весьма эффективной) конструкции, инструкции при программировании алгоритмов, описанных графами переходов.
Есть несколько методик как применять.
Я "придумал" разделение автоматов на базовые и технологические и описал взаимодействие между ними. Кто-то применяет SWITCH-технологию по-другому (статьи есть на http://is.ifmo.ru/).

[Тотолотто]

Спасибо,

прочитал ещё раз Ваши обе статьи повнимателней. Так же нашёл конвертер Visio2Switch, к сожалению пока не исробовал из за отсутствия пакета Visio. Всё таки создаётся впечатление, что использование SWITCH технологии по вашему методу (или вообще) занимает нааамного больше времени, чем ООП, т.е. привычный метод программирования.
Проект описаный Вами смотря на тех. описание задачи относительно громоздкий и очень ответственный, но разработка 125-ти !!! автоматов, не слишком ли это?
А ещё я не понимаю зачем использовался пакет ЛабВью, если конвертер выдаёт Сишный код? Неужели только как графический набор красивых индикаторов? Ведь для этого есть Measurement Studio.

И всё таки я бы очень хотел так же как и Вы щёлкать эти автоматы как орехи. Мне кстати очень помогла разобраться в составлении автоматов статья Дугласа, что не скажешь о других статьях. У Харела только теория (но она так и называется), а у Вас в статье вид на проект сверху и издалека, я бы пожелал разобрать один средненький автоматик по частям и подробно описать его, так же мне не хватает последнего шага, где все автоматы сливаются в одну программу. В статье в принципе есть одна блок-диаграмма, но она объясняется не очень подробно.

Есть ещё два мелочных вопроса:

Не смог разобраться с нумерацией состояний в Ваших автоматах (10, 66, 99). Не подскажите ли где это описано?

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

Огромное спасибо за Вашу идею, я надеюсь она поможет мне в будущем эффективнее программировать.

[Тотолотто]

Сообщение от WaW

Я "придумал" разделение автоматов на базовые и технологические и описал взаимодействие между ними. Кто-то применяет SWITCH-технологию по-другому (статьи есть на http://is.ifmo.ru/).

Главную мысль я понял - разделение труда - но ведь это основа всего программирования вообще, и не считается новой.

[WaW]

Сообщение от Тотолотто

...прочитал ещё раз Ваши обе статьи повнимателней. Так же нашёл конвертер Visio2Switch, к сожалению пока не исробовал из за отсутствия пакета Visio. Всё таки создаётся впечатление, что использование SWITCH технологии по вашему методу (или вообще) занимает нааамного больше времени, чем ООП, т.е. привычный метод программирования.

Скачайте Word-ский документ http://slil.ru/22476389. Там можно будет растянуть рисунки до 100 процентов.
Все-таки прочитали статьи невнимательно.
Я пользуюсь своим конвертором для того чтобы потом вставить текст в Formula Node пакета LabVIEW (Formula Node "понимает" синтаксис Си), а конвертер Visio2Switch генерит текст целой программы на Си и я им не пользуюсь - зачем?.

Сообщение от Тотолотто

Проект описаный Вами смотря на тех. описание задачи относительно громоздкий и очень ответственный, но разработка 125-ти !!! автоматов, не слишком ли это?.

Так елы-палы, для того чтобы показать эффективность и приведен сложный логически проект!

Сообщение от Тотолотто

А ещё я не понимаю зачем использовался пакет ЛабВью, если конвертер выдаёт Сишный код? Неужели только как графический набор красивых индикаторов? Ведь для этого есть Measurement Studio.

Про Сишный код ответ выше...
Не очень понял критерий выбора программного средства - LabVIEW или Measurement Studio... Если заводить разговор о выборе, то это будет отдельная большая ветка форума.
Делайте где Вам нравиться - какие проблемы? Метод работает везде.

Сообщение от Тотолотто

...я бы пожелал разобрать один средненький автоматик по частям и подробно описать его, так же мне не хватает последнего шага, где все автоматы сливаются в одну программу. В статье в принципе есть одна блок-диаграмма, но она объясняется не очень подробно.

В http://is.ifmo.ru/progeny/_metod065.pdf подробно расписан простенький алгоритм от начала до конца - в нем всего два базовых и два технологических автомата.
Базовые и технологические выполняются параллельно. Приводить это в графическом коде на языке G - это не реально.

Сообщение от Тотолотто

Не смог разобраться с нумерацией состояний в Ваших автоматах (10, 66, 99). Не подскажите ли где это описано?

Опять-таки смотрите http://is.ifmo.ru/progeny/_metod065.pdf.
Нумерация вообще-то предполагалась вольная. А а конкретно здесь просто сильно отличными от других цифрами обозначены особые состояния - например, 10 - неустойчивое состояние, зависящее от времени, 66 - неисправность, 99 - начальное или конечное состояние и т.д. Это не принципиально.

Сообщение от Тотолотто

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

Наличие одновременно нескольких диалоговых окон на экране обусловлено параллельностью работы разных объектов и групп объектов. Тут ничего не поделаешь и кстати автоматный подход позволяет без проблем реализовывать именно такой режим.
Как выводить на экран диалоги - забота программиста - придумайте свой способ, главное чтобы не прерывалась нормальная работа установки и одновременно с этим оператор должен быть своевременно информирован о неисправности.
Естественно, когда окон на экране много - это мягко сказать "плохо". Но подразумевалось, что диалоги будут вылезать только когда нужно по нормальному ходу работы установки (и их общее количество на экране будет небольшим, 1-4). А если случается ненормальная ситуация, то оператор вообще-то должен реагировать сразу...

[Тотолотто]

Сообщение от WaW

Скачайте Word-ский документ http://slil.ru/22476389. Там можно будет растянуть рисунки до 100 процентов.

К сожалению скачать не получается, проверьте линк (кстати .avi, о котором говорится в начале этой темы форума тоже не скачивается). Доходит только до 2% и зависает.

Сообщение от WaW

Я пользуюсь своим конвертором для того чтобы потом вставить текст в Formula Node пакета LabVIEW (Formula Node "понимает" синтаксис Си), а конвертер Visio2Switch генерит текст целой программы на Си и я им не пользуюсь - зачем?.

А можно ли бесплатно достать Ваш конвертер?

Но ведь если Formula Node понимает синтакс Си, то можно объединить все, сгенерированые с помощью Visio2Switch файлы, в один и запихать в Formula Node.