Комментарии 24
Пришло, так сказать, время перейти на новый уровень качества среды
Чтобы перейти на новый уровень качества среды - нужно найти в себе мужество осознать и принять недостатки текущей. А то, что у вас сейчас - это даже не среда, а просто нагромождение диалоговых окон без всякого единого стиля и даже единого языка (русский и английский вперемешку и даже в разных регистрах!). Уж извините.
Среда для подобного рода задач реализуется через MDI - проверенное временем понятное каждому. Это не значит именно "многодокументность". Это прежде всего меню - создать/загрузить проект, скомпилировать/отладить, etc. Это специализированные окна (не диалоговые), в которых будут списки ваших автоматов, переменных, диаграммы, графики, ошибки и прочее. А диалоговые окна появляются по клику по элементу списка, а не содержат этот список внутри себя,
как тут
Чтобы не доводить дело до крайностей - до проявления мужества или, не дай Бог, проведения каких-либо специальных мероприятий, я в свое время (и достаточно давно) решил пойти по пути здавого смысла. Да, безусловно, интерфейс - важная часть, но это в первую очередь "одежка", а основное все же - смысл. В просторечии - ядро среды. Ее, скажем так, - мозги. На программистском сленге - вычислительная модель. Т.е. то, из-за чего и затеялся "вертеж". И то, что поначалу было только "схемкой" теперь стало реальность. Для кого-то, может, не столь модно "одетой", как того хотелось бы...
Я, конечно, думал про интерфейс, про то, каким он должен быть. И, безусловно, хотелось, чтобы он был красивым, наглядным, современным и далее по списку. Но я не модельер, а простой технарь. Даже где-то - программист ;) А потому, он (интерфейс), в конце концов, получился такой, какой есть. Он мне удобен.
Но, если теперь поговорить о здравом смысле, то в ВКПа без проблем можно создать любой интерфейс, т.е. любую "одежку". Это легко можно сделать через создание соотвествующей библиотеки. Как технарь, создав такую возможность, я просто перестал "париться" по его (интерфейсу) поводу. Одевайте, как хотите.
Но трогать мозги - другое дело. Тут уж, действительно, нужно мужество, чтобы переключиться на другое мышление - автоматное. Я через это прошел и потому знаю, о чем говорю.
Вы обратили внимание на "одежку". И Ваши замечания, наверное, даже справедливы. С чем-то я вполне согласен. Но, еще раз, как технарю, мне пока не до одежки. Я больше "кайфую" от того, что мне удалось убрать множество косяков. А, ведь, есть и другие, которые время от времени проявляются. Я больше доволен тем, что происходит это теперь достаточно редко. А есть планы и по развитию среды. Нет - не "одежки", а - функциональности, повышению надежности и т.д. и т.п. Многое - уже получилось, что-то - надо сделать, т.к. почти ясно как. Так что заняться есть чем...
Другими словами. Пока мне комфортно в существующей "одежке". Выявляется "дырочка" - латаю. Но в первую очередь думаю о "мозгах". И вот к ним у меня серьезных замечаний почти нет. А потому хотелось бы поговорить в первую очередь о них. Может я чего не вижу?
А интерфейс - дело десятое. Кому не нравится - нет проблем создать свой. Вот такой, думаю, вполне здравый смысл. Каждый должен зханиматься своим делом: кто-то дизайном ,а кто-то - мозгами. Я сосредоточен на последнем. И главное здесь, чтобы они (модельер и технарь) помогали друг другу, а не мешали.
Что означает запись "^x3x4^x5/" ? Я нутром чую, что это событие по которому осуществляется переход от одного состояния к другому, но простите, как это расшифровать ? С моей точки зрения, описания программы следовало бы начать с описания языка и структур данных которыми она оперирует. Я только сейчас догадался, что вся Ваша программа это симулятор конечных автоматов с очень странным представлением. Почему Вы не использовали что-то более стандартное (State Chart XML) ? Вот пример описания FSM котрый ясен как божий день:
<state id=s">
<transition event="e" cond="x==1" target="s1"/>
<transition event="e" target="s2"/>
<transition event="*" target="s3"/>
</state>Не нравится XML ? Используйте JSON (JFSM):
{
"name": "MealyStateMachine",
"model": "mealy",
"events": [
{
"name": "EventOne",
"type": "input"
},
{
"name": "EventTwo",
"type": "output"
}
],
"states": [
{
"name": "StateOne"
},
{
"name": "StateTwo"
}
],
"transitions": [
{
"name": "TransitionOne",
"from": "StateOne",
"to": "StateTwo",
"trigger": "EventOne",
"output": "EventTwo"
},
{
"name": "TransitionTwo",
"from": "StateTwo",
"to": "StateOne",
"trigger": "EventOne",
"output": "EventTwo"
}
],
"initialState": "StateOne"
}Ваша же криптограмма, будучи сохраненной в файл, не подлежит прочтению человеком.
Что означает запись "^x3x4^x5/" ?
Так на объеснение этого и приведены ссылки (см. [1]).
Почему Вы не использовали что-то более стандартное (State Chart XML) ? Вот пример описания FSM котрый ясен как божий день:
Стандартом для автоматов является теория автоматов, которая рассматривает различные способы описания автоматов. Поэтому мое описание максимально приближено к этому стандарту, т.е. смотришь на граф (стандартная графическая форма описания автомата) и переводишь ее в табличную форму описания автомата (см. строки таблицы переходов в списке диалога FAutomaton). Куда уж проще и нагляднее?
А как перевести Ваш "божий день" в нормальную форму - граф, таблицу переходов не могу, если честно, представить. Для сравнения, чтобы было понятно (какой автомат Вы закодировали), закодируйте хотя бы автомат .Sensors2 (см. рис. 3 выше). Заодно сравним и с моим представлением. Если будет нагляднее, может, я свою "криптограмму" и изменю.
Я так понимаю , "божий инструмент", предложенный checkpoint, не позволяет описать простой автомат? ;)
И еще. "Криптограмма", сохраненная в файл, не предназначена для чтения человеком. Для него - в данном случае есть табличное описание автомата в форме FAutomaton. Кстати, на C++ описание автомата будет фактически таким же. Примеры этого есть в моих статьях (кстати, в той же [1]). И вообще, если на что-то не можете найти ответ, то по логике он должен быть по ссылке. Читайте внимательнее. Ссылки-то зачем-то тоже даются?
Причудился кошмар - описание автомата в формате XML.Ну, или крайняк - JFSM. Представил также, что, видимо, есть Библия программиста в которой именно они сотворили Мир за шесть (или семь?) дней. И тогда все, что не описано в понятных им, как "как божий день", программных стандартах просто не существует. Т.е. теории автоматов - просто нет. Ну, не вписываются ее автоматы в программные стандарты. Академик Грушков, как и фон Нейман - рыдают, т.к. родились раньше времени - в допрограммистское время.
Но, вдруг, выясняется, что эти самые стандарты бессильны перед весьма простеньким автоматом. По крайней мере, на мою просьбу описать его так и не откликнулись. В этом смысле просто отмолчаться - не лучший вариант. Сказавши "а", нужно быть готовым сказать и "б".
Каким бы классным не было программирование, оно должно отвечать существующим реалиям и формальным териям. Все остальное - от лукавого. Когда я смотрю на описание, не кночи упомянутых, стандартов - оторопь берет. Нет, я их не отрицаю. Если они есть, но, наверное, они кому-то наужны. Но зачем и для чего? Но, если дан ответ на эти вопросы, то нет проблем по совсем простому описанию автомата в обычной для теории автоматов форме создать описание в любом стандарте - том же формате XML или JFSM. Но... зачем нужна "гора", которая гарантированно родит "мышь"?
Я не против стандартов. Они хорошая и полезная штука. Но всему свое место. Не надо их пихать куда попало. Сначала "программисту" нужно было бы разобраться с самим понятием автомата, чтобы понять: достаточно ли стандарта, чтобы его описать, удобно ли и компактно ли это будет и т.д. и т.п. Здесь "туча" проблем. Т.е. прежде, чем что-то советовать, нужно "иметь мужество" за них отвечать. А просто "слинять" - далеко, как уже выше сказано, далеко не самый лучший вариант.
Вот, как-то так... Прошу прощения за достаточно резкий коммент, но ... дилетанизм в определенных вопросах, если честно, достал. Будьте внимательнее, учитывайте и хотя бы просматривайте те ссылки, которые приводятся. От ошибок никто не застрахован. Но есть такие, за которые (и на которые) надо отвечать.
Ну хоть кто-то у нас занялся этой темой. Да, корявенько получилось. Надеюсь, автор выслушает критику и доведёт интерфейс до вменяемости, чтобы он не вызывал отторжения у людей. По-моему, с записью условий и действий автор перемудрил. Проще и понятней придерживаться принятой в книжках нотации, расшифровывая их рядом на экране или при наведении на них мыши.
Вопрос: а как созданный автомат загрузить в контроллер и исполнить? Какие задумки на сей счёт? Как отлаживать автомат по нарисованной схеме?
Главное, чтобы этот интерфейс не вызывал отторжения у автора. Пока терплю ;) Другие могут предложить (было бы весьма интерсно посмотреть) и даже реализовать свой. Пока, если честно, у меня подобный "пазл" как-то не складывается.
В чем конретно я перемудрил? Не признаю гаданий. Если по поводу символа отрицания - ^, то хотелось бы посмотреть на другие варианты.Остальное - как в книжках по автоматам.
По поводу "загрузить" и "исполнить". Может быть несколько вариантов. Самый реальный описан в моей статье, т.е. просто ручками. Это мой текущий вариант работы. Есть другой на мой взгляд очень хороший и даже красивый вариант: связать, например, по modbus ПК (с ВКПа) с ПЛК. Дальше создаем автоматы в ВКПа, общаясь в реальном времени с оборудованием через ПЛК, имея, конечно, полный доступ к его памями. Отработав все, реализуем автоматы, как в указанной статье. По сути это аналог режима отладки обычной среды разработки для ПЛК. Только в данном случае средой разработки выступает ВКПа.
Что мешает использовать для отрицания запись "!x1"?
Почему не писать на дугах что-то типа "t1/a1", а рядом расшифровывать? Ведь условия и действия могут быть развесистыми.
t1 := !X001 * X002;
a1 : Y001=true, flag=false
По поводу связи с ПЛК.
Дельта, являющаяся развитием идей ПЛК от Мицубиси, исполняет байт-код. В системе команд этих ПЛК, как известно, есть поддержка STL, позволяющая реализовывать КА. У меня есть рантайм, совместимый с FX2N от Мицубиси, но я пока не могу придумать, как совместить работу программы, написанной в том же GX Works2 и ВКП. Создавать POU, в который импортировать переменные из CSV-файла, а КА , транслированный в IL, копипастить в окно редактора POU? Чё-то как-то телодвижений много, по-моему...
Разницы большой между !x1 и ^x1 нет. Все это условности. Мне больше нравится вторая форма.
Про дуги. Не надо путать имена входных каналов - x1, x2, ... xM, y1, y2, ...yN и функции-предикаты и функции-действия им сопоставленные. Автомат по определению - это MxN-полюсник. На дугах пишутся имена каналов, а функции, которые могут быть достаточно сложными - расшифровываются рядом. Так точнее. Хотя, может быть, есть и некоторые проблемы с наглядностью. Но и расшифровка непосредственно на дугах содержимое предикатов и действий - лишнее загромождение графа, да и не все можно порой записать, т.е. уместить. Все это наглядно демонстрируют автоматы, созданные програмистами. Они упрямо хотят вписать в граф автомата на его переходы и в состояния явно невписуемое :).
По поводу связи. В моем варианте (когда связь ПЛК-ПК есть) проектирование ведется на языке автоматов (те же визуальные автоматы в форме FAutomaton). А после того, как все отработано переложить автомат пусть даже ручками - не большая проблема. Делается "по щелчку" на STL или LD (см. опять же мою ссылку). Конечно, хорошо бы иметь компилятор, но ... нужно быть реалистом. Это все возможно, но требует не только денег на реализацию, но и знаний, как это сделать.Часто есть одно, но нет другого или наоборот ;)
> Разницы большой между !x1 и ^x1 нет.
Разница есть. Не я один споткнулся на чтении выражений. По-моему, есть повод задуматься о смене нотации.
В Инете попадались программы рисования автоматов. Там вопросов с изображением автоматов и нотацией не возникало.
Как один из способов описания алгоритма работы программы ВКП выглядит неплохо, но нужна интеграция с ПЛК. Плюс нужно формальное описание способа хранения КА, чтобы была возможность его трансляции на какой-нибудь язык программирования и отладки, пусть даже и не на ПЛК.
В ПЛК есть SFC, позволяющий описывать автоматы и превращать их в исполняемый код. Без решения вопроса интеграции ВКП со средами программирования и генерации кода он зависнет в воздухе и кроме автора вряд ли кем будет использоваться в повседневной работе.
Вы заставили меня задуматься;) Я, конечно, не уберу ^, но, возможно, добавлю !. Как бы на любителя.
Те "рисовалки", которые мне попадались, меня не устраивали. По многим причинам. Поэтому просто рисую автоматы в Visio.
Интеграция, как уже сказал, мне видится через полный доступ ко всей памяти ПЛК, используя любой протокол. Например, modbus. Сделали проект, отработали, отладили дальше - в код ПЛК. Сейчас автоматы - ручками. Кодирование - это самое простое в программировании. А дальше - как получится, но, скорее всего, этим я заниматься не буду.
Да, SFC есть. Есть даже официальный документ, в котором описано кодирование на нем автоматов. Но - не то..Я, конечно, поглядывал в его сторону (и даже давно), но, как оказалось, проще сделать на LD. Так, как я уже этот процесс описал.
Ну, а насчет использования. Как сделаю связь по протоколу, то, может, даже опишу и тогда будем смотеть, что с этим делать. По крайней мере, это самый реальный вариант интеграции ВКПа с ПЛК. Подобные вещи я делал (пусть и не с ПЛК и, к сожалению, не по modbus). Но здесь все достаточно понятно, т.к. делается аналогично, да и цели ясны ;).
> Сделали проект, отработали, отладили дальше - в код ПЛК.
Каким образом, ручками? А смысл? Тогда проще на SFC рисовать.
> как оказалось, проще сделать на LD
Например, в ПЛК от Мицубиси есть STL, на котором КА реализуются намного компактней, чем на LD. И зачем создавать велосипед, когда он уже есть и ездит быстрее изобретаемого хотя бы потому, что встроен в рантайм ПЛК, поэтому не тратит ни лишней памяти программ, ни времени на интерпретацию байт-кода.
Короче, надо искать способы интеграции ВПК с ПЛК, ну или писать свой рантайм для ПЛК. Иначе повторится история с языком Дракон, когда исписали кучу книжек, статей, но за 40 лет так и не смогли создать среду программирования и отладки для программ на Этом языке.
Поддерживаю несколько проектов на PHP и Google Apps Script, то есть постоянно переключаюсь - модернизирую.
Без ДРАКОНа и DRAKON Editor - не справился бы читать портянки кода, перегорел и бросил.
А с ними - открываю схемы, врубаюсь, улучшаю, генерирую код.
Код отлаживаю в специальных IDE - PHPStorm, VSCode.
Кто-то из мудрых пояснил - вы уже создаёте программы в автоматном стиле, даже не зная об этом, только Ваши автоматы получаются плохими.
В схеме каждая икона, каждая линия и есть состояния автомата.
Некоторым большие схемы трудно понимать.
А понимать тыщи строк им легче.
Вот пока незавершённый проект.
Он сгенерировал пока 19 килобайт кода, 500 строк (пока).
Что лучше понимать схему или код?
Схемы понимать проще.
ДРАКОН в его нынешнем виде фигня полная. На нём невозможно ни написать, ни отладить программу. Пока он тупая рисовалка алгоритмов, не более. И это результат за 40 лет существования! Обо всём этом я писал Паранджанову у него на сайте, но там засилье любомудрствующих теоретиков и пустозвонов, считающих, что ДРАКОН и должен быть таким, посему я плюнул на этот Дракон, хотя он мог бы стать хорошей основой для программирования тех же ПЛК.
ДРАКОН в его нынешнем виде фигня полная.
Вы от него много хотите ;) Он достаточно наглядный и хороший пример визуального програмирования. Причем использованный в реальной работе. Другое дело, что можно критиковать или обсуждать вычислительную модель, положенную в его основу. Это модель блок-схем. Но в рамках даннной модели до сих пор работают почти все языки программирования. Так что в этом смысле он им соотвествует.
ДРАКОН можно было бы внедрить почти в любой язык програмирования с учетом уже современных их возможностей, но ... Блок-схемы это все же программная модель, которую давно пора заменить на что-то другое. Например, на те же автоматы ;) .
Что лучше понимать схему или код?
Ответ просто один - схему. Но ее еще ужно создать.
Кто-то из мудрых пояснил - вы уже создаёте программы в автоматном стиле, даже не зная об этом, только Ваши автоматы получаются плохими.
Было бы хорошо, если бы "мудрецы" пояснили, как из Ваших блок-схем создать автоматы. Это реально просто - стандартная процедура. Вот Ваша блок-схема, подготовленная к рисованию графа-автомата:
Процедура разметки блок-схемы
А так, Вы на правильном пути:)
Спасибо за подготовку схемы.
Похоже начинаю догадываться к чему Вы меня сподвигаете - создать преобразователь ДРАКОН схем в абстрактный автомат, и можно будет находить в автомате ошибки, необработанные (непроявленные) состояния, даже формально верифицировать?
— А всеми вооружёнными силами республики?
— Малость подучиться — смогу и вооружёнными силами.
Вы меня сподвигаете - создать преобразователь ДРАКОН схем в абстрактный автомат,
Совсем нет. Наоборот, хочу отговорить от этой мысли ;) Вы только зря потратите свои сылы. Просто, преобразуя ручками блок-схемы в автоматы, Вы поймете, чем автоматы отличаются от блок-схем. Это, первое. Второе - почему здесь абстрактные автоматы ни при чем - нужны структурные автоматы (с абстрактным состоянием). Третье - созреете к переходу от отдельных автоматам к сетям. Это, чтобы параллельно программировать.
Да, чуть не забыл, нужно выбрать, а, может, и создать свой метод кодирования автоматов для того языка программирования, на котором Вы работаете. Все это лучше сначала делать ручками. Через них просто лучше доходит. А уж потом, если будет желание, время и понимание того, что это просто необходимо и без этого просто жизни нет, то тогда можно и "создавать преобразователи".
Т.е. сначала нужно врубиться в идею автоматного программирования, а уж потом приступать к ее реализации. Не надо ставить "телегу впереди лошади". Во, как-то так - на пальцах, так сказать.
Это я делюсь своим опытом :) Конечно, доходить до всего самому сложно, долго и тяжело, но приготовьтесь и к этому... Хотя, думаю, Вам будет много проще, чем это было мне ;) Плохо ли хорошо, но все это описано в моих статьях здесь на Хабре. Осталось только... "малость подучиться" :)
Зашибись вы SWITCH-технологию опустили xD
Он достаточно наглядный и хороший пример визуального програмирования
Дракон- это не язык программирования, а "образ мышления", на что мне указали его адепты. Он, по их мнению, предназначен не для программирования, а для рассуждений. Видимо, поэтому написать и отладить на нём программу нельзя.
Похоже начинаю догадываться к чему Вы меня сподвигаете - создать преобразователь ДРАКОН схем в абстрактный автомат
Этих преобразователей уже вагон написан, но никто, кроме авторов ими не пользуется. Догадываетесь почему?
Дракон- это не язык программирования, а "образ мышления", на что мне указали его адепты.
Тут надо бы понимать, что они (адепты) понимали под "образом мышления". Программист проектирует алгоритмы. В этом смысле язык программирования - текстовая форма алгоритма, а граф (блок-схема, автомат и т.п.) - графическая. Понятно, как первая превращается в код для процессора. То же самое можно сделать и с графической формой. В конце концов можно "мыслить" образно графом, нарисовать его, а потом ручками перейти от крафической формы к текстовой. Но первый Ваш "образ" - это граф. Этим отличается отличие "графического мышления" от "текстового". Но и в основе ДРАКОНА и любого языка программирования понятие блок-схемы. И вот в этом смысле адепты были не правы, т.к. используете Вы ДРАКОН или нет, но в основе подобного мышления одно - "блок-схемное мышление".
Когда Вы используете автоматную модель представления алгоритма, то у Вас поневоле будет и другое мышление - автоматное. Я, например, достаточно давно не "мыслю" блок-схемами, а - автоматами. И это, действительно, другое "мышления". От "блок-схемного" отказаться сразу конечно сложно, но вполне возможно. Это я говорю, основываясь на собственном опыте.
Можно, конечно, считать, что "графическое" и "текстовое" - это разные формы мышления. И где-то это так. Но все же кардинальным образом мышление изменяет используемая модель вычислений. В этом смысле ДРАКОН не меняет мышление. И только "автоматное мышление" - иное мышление, как, например, существует "объектное .мышление".
Этих преобразователей уже вагон написан...
В этом нет ни чего плохого. Другое дело, ЧТО они преобразуют. Догадываетесь о чем речь?
ВКПа. Введение, ч.1. Визуальное проектирование автоматов