Монограф

[Михайло]

Если не ошибаюсь Шалыто использует в основе инструкцию условного перехода JMP?

[CHANt]

Не совсем так, на Си возможностей больше чем на МЭКе,

[Михайло]

Возможности-то возможностями, но удобства и простоты лишаемся... По сравнению с обычными AND, OR, NOT, R, S, MOVE. А JMP - это лишь один из вариантов, не самых удачных по моему мнению.

[CHANt]

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

[Михайло]

Ааа.. Вон как Вы работаете!

[Бондарев Михаил]

пишешь задачку на паскале\си, конвертируешь в асм, компилишь и заливаешь...

ЫЫЫ , а как насчет напрямую из Паскаля/Си скомпиировать и залить? ;)

[Степа]

Но, мы тут не обсуждали конкретные среды и их возможности, че какашки всякие вспоминать...

Это-то понятно... Просто некоторые, с позволения сказать, среды больше вредят практической работе.

Если где -то остановилось выполнение программы...

А если не остановилось? Идет выполнение, по выходам понятно, что неверное, но остановки нет.

а как насчет напрямую из Паскаля/Си скомпиировать и залить?

А не обнаружилось таких, чтобы делали бинарник напрямую из паскаля\си и чтобы позволяли хотя бы на эмуляторе пробежаться по программе /MPLab это позволяет, немного неудобен по сравнению с Proteus, но откровенные ляпы программы выловить можно/. Конечно, может и были хорошие платники, но лично мне было неудобно просить денег на покупку ПО, работу которого я видел только на красочных картинках.

Теперь по поводу моего подхода...
Граф выглядит так:

Над ребром - условие перехода, под ним - действие, выполняемое на переходе. Ребро со свободным переходом /на рисунке это переход из состояния 12 в состояние 13/ имеет наименьший приоритет /по понятным причинам для случая, показанного на рисунке, приоритет не имеет смысла/. Номер в вершине является и номером состояния и содержится в соответствующей ячейке ПЛК.

Некоторые преподаватели /как ни странно, но к этому нюансу цеплялись только преподаватели/ считают, что между состояниями 9 и 10 имеет место быть гонка состояний. Это разумеется не так /да это и так видно, по условиям перехода/.

Тут, на рисунке, есть одна ошибка /кстати, впервые только что обратил внимание, хоть этому графу уже шесть лет и его достаточно активно пользуют наладчики при поиске неисправностей/: движение к S23 или к S24, включаемое при переходе из состояния 2 в состояние 3, остается включенным и при переходе из состояния 3 в состояние 4, а это не показано на графе.

При таком способе состояния рисуются небольшими, а все действия отображаются там, где и так места много - над и под ребрами. Этот подход позволяет рисовать довольно сложные графы в читабельном виде на одном листе A4. Пользоваться бОльшим форматом при наладке и поиске неисправностей показалось крайне неудобно. В частности для той установки, чей алгоритм изображен на графе, вся нужная для наладки и определения неисправностей документация уложилась на одном стандартном листе А4 с двух сторон: с одной граф, с другой - таблица входов-выходов /которая чаще всего не используется - есть таблица символов/.

[Михайло]

Ребро со свободным переходом

Лучше: "Ребро с безусловным переходом".

Некоторые преподаватели /как ни странно, но к этому нюансу цеплялись только преподаватели/ считают, что между состояниями 9 и 10 имеет место быть гонка состояний. Это разумеется не так /да это и так видно, по условиям перехода/.

Действительно гонки нет. Но при определенных условиях у тебя гонка может возникнуть между 10 и 12 состояниями, например.

Потом помнишь мы говорили, о том, что на интуитивном уровне должно восприниматься суждение "вершина=состояние". У тебя это интуитивное правило нарушается. Например, вершина 3. Система, находясь в этой вершине, может пребывать в двух разных состояниях - состояние "к S23 и F1+" и состояние "к S24 и F1-". Иными словами, при известном номере вершины поведение системы остается неопределенным, нужна дополнительная информация.
Если, например, организовывать графический элемент "список событий" на панели оператора, то достаточно было бы опросить состояние системы и вывести сообщение "каретка движется к конечнику S24", но так просто в твоем случае не получается. Понял мысль?

[CHANt]

А если не остановилось? Идет выполнение, по выходам понятно, что неверное, но остановки нет.

Сложно сказать что Вы имели ввиду, так как листинг программы соответствует изображению графа в каждой строчке, в каждом символе. Если напутано в графе - код всего лишь повторяет его. При необходимости протоколируется переходы и состояния входов и выходов. Вот и всё, все ошибки тут же налицо. Собственно и Ваш граф с легкостью ложится в мой шаблон. Но, мы обсуждали два вопроса:
1 недостаток - это взаимосвязь между алгоритмами, а не в самом алгоритме. Это особенности среды Step7 и у Михайло совершенно справедливые замечания, так как при организации взаимосвязей все ложится на внимательность программиста и массу условностей, которые приходится держать в голове. ЗЫ: Сам уж себя покритикую :D
2 "недостаток" - листинг на языке IL (STL) изобилующий переходами JMP. Тут я не согласен с Михайло, так как шаблон всего лишь повторяет граф и как он реализован (я знаю версии и на SCL) не важно. Ошибся в алгоритме, код повторил ошибку, а не внес новую. А чтобы не вносить ошибки при наборе вручную кода, лучшее решение - это создание конвертера, кои примеры я и привел, в виде ссылок, ранее.

Теперь по поводу моего подхода...

Листинг этого графа приведите, плиз. Тогда понятно станет как конкретно Вы реализуете его. Да, с 9 и 10 состоянием никаких проблем нет. Если требуется повторение одной и той же операции, то вполне корректно. Тем боле что Вы тормозите переходы с помощью таймера. А вот вариант 10 - 12-13-8-9 интересен :)

[Михайло]

"недостаток" - листинг на языке IL (STL) изобилующий переходами JMP. Тут я не согласен с Михайло, так как шаблон всего лишь повторяет граф и как он реализован (я знаю версии и на SCL) не важно. Ошибся в алгоритме, код повторил ошибку, а не внес новую. А чтобы не вносить ошибки при наборе вручную кода, лучшее решение - это создание конвертера, кои примеры я и привел, в виде ссылок, ранее.

Я не пользую конвертеры, поэтому данный вопрос актуален для меня.

А вот вариант 10 - 12-13-8-9 интересен :)

Это вы про гонку состояний?

[CHANt]

Больше наверное про переход 13-8, откуда бы ему вырисоваться. В 10 конечное (действий нет), переход на 12 (действий нет), переход на 13 по истечению таймера и тут логичен уход на 14, а дуга в состояние 8 как-то не вяжется. Откуда начальному состоянию взяться? Перезагрузка контроллера?
Ну и интересна реализация самого графа в коде.
Конвертер..ммм..времени нету.А так можно ведь и LD (LAD) на выходе иметь. Идея хорошая.

[Степа]

Лучше: "Ребро с безусловным переходом".

Пусть будет так...

Но при определенных условиях у тебя гонка может возникнуть между 10 и 12 состояниями, например.

Обратного ребра от 12 к 10 нет.
Тут состояние 12, по сути, нужно, чтобы было удобно "собрать" все переходы из 8, 9, 10 и 11 состояний и выдержать паузу. Исполнитель перемещения "вперед" и "назад" достаточно резв и если без паузы сменить ему команду, можно разломать механику. Исполнитель перемещения "вверх" и "вниз" достаточно инертен и сам выдерживает необходимую паузу, поэтому на проходе 0-15-1-2 пауза не выдерживается.
Вот что в этом "углу" не совсем кошерно, так это то, что не будет отрабатываться датчик "На позиции" если граф ушел в состояние 12 с плотненько сработавшим датчиком "Конечное" - перехода 13-8 не случится.

Потом помнишь мы говорили, о том, что на интуитивном уровне должно восприниматься суждение "вершина=состояние". У тебя это интуитивное правило нарушается.

В данном конкретном случае совершенно неважно к какому датчику отрабатывается движение. Надо, чтобы оно было, поэтому тут нет деления на отдельные ветви. Хотя можно разделить состояния 3 и 4 и провести две параллельные веточки /и заодно избавиться от флажка F1/, этому ничего не мешает /на модернизации, кстати, можно так и поступить/...

Если, например, организовывать графический элемент "список событий" на панели оператора, то достаточно было бы опросить состояние системы и вывести сообщение "каретка движется к конечнику S24", но так просто в твоем случае не получается. Понял мысль?

Мысль понял, отвечаю. Для данной системы нет списка событий и не будет. В настоящий момент все это показывается светодиодами на мнемосхеме:
- не горит - не сработал конечник
- горит - сработал конечник
- мигает - в направлении этого конечника идет движение
Индикация обрабатывается отдельным блоком: выход включен - мигаем, нет - в зависимости от состояния входа.
При давно ожидаемой модернизации аппаратная мнемосхема будет заменена на программную /панель оператора - типа маленького панельного ПК со встроенной собственной SCADA/. Ни рисунок пока не собираемся менять. Разве что дополнительно запланировали текстом отмечать обнаруженные непорядочки.

Да, с 9 и 10 состоянием никаких проблем нет. Если требуется повторение одной и той же операции, то вполне корректно.

Тут не для повторения, а чтобы надежно съехать с уже обработанного датчика. Т.е. если сработал датчик "На позиции" пока не истек таймер, то считается, что это уже обработанный.

Листинг этого графа приведите, плиз.

Весь или отдельные переходы? Если выложу весь, то имена переменных потеряются - MicroWin на экспорте имена меняет на их адреса. А по цепям - долго.

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

Код: Выделить всё

LD     Цикл1
AB=    Сост1, 14
LD     Наладка_1
A      Назад_1
A      ТАКТ_1
OLD
AN     Исходн_1
A      Вверху_1
=      УНазад_1

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

Больше наверное про переход 13-8, откуда бы ему вырисоваться.

Там люфты жуткие...

[CHANt]

Весь или отдельные переходы? Если выложу весь, то имена переменных потеряются - MicroWin на экспорте имена меняет на их адреса. А по цепям - долго.

А прямо в микровине проектик, если не сложно. Интересует-заход в состояние, выход из него, переход в следующее - скелет.

[Михайло]

Странно вы оба (Степа и CHANt) понятие "гонка состояний" понимаете... Во-первых, в программной логике гонка состояний может возникнуть только в реализациях, позволяющих раздвоение состояний или когда два графа, работающих параллельно, включают и выключают один и тот же бит. У Степы, я знаю, раздвоение запрещено, поэтому гонки состояний не будет. Во-вторых, вы думаете, что гонка состояний - это быстрое переключение одного и того же бита при быстром перепрыгивании с одной вершины на другую. Я же думаю, что это просто ошибка в алгоритме, вряд ли быстрые скачки были задуманы автором. :) Как нарисовал, так граф и исполнил...
Гонка состояний - это включение и выключение бита в пределах одного цикла (скана) программы. Чтобы не было гонки, достаточно для каждой вершины определить приоритет переходов.

Мысль понял, отвечаю. Для данной системы нет списка событий и не будет. В настоящий момент все это показывается светодиодами на мнемосхеме:
- не горит - не сработал конечник
- горит - сработал конечник
- мигает - в направлении этого конечника идет движение

Кстати, я миганием тоже активно пользуюсь так же как ты.
А на будущее рекомендовал бы с автомата Мура перейти на автомат Мили. У Мили не требуется повторять действие по несколько раз, ведь вершин всегда меньше, чем переходов. Использование флажков типа F1 - тоже не порядок, чем Вам лишняя вершина не угодила? Это же удобнее!

Кстати, кто-нибудь из Вас пользовался Stateflow в пакете MATLAB?

[Степа]

Странно вы оба (Степа и CHANt) понятие "гонка состояний" понимаете...

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

У Степы, я знаю, раздвоение запрещено...

Я бы сказал так: алгоритмом обработки автомата не предусмотрено разделений.

Гонка состояний - это включение и выключение бита в пределах одного цикла (скана) программы.

В данном случае это в принципе невозможно: за один такт отрабатывается только одно состояние...

Чтобы не было гонки, достаточно для каждой вершины определить приоритет переходов.

В общем виде - нет.
Вообще, мне почему-то кажется, что понятие "приоритет перехода" несколько ущербно. Максимум, где может фигурировать понятие "приоритет", так это выход на свободный или безусловный переход - на него однозначно должен быть выход после проверки условий всех условных переходов. Для условных переходов в случае если возможно одновременное возникновение условий для двух разных переходов, создать несколько состояний. Нотация проще /не нужно на графе помечать приоритеты/ и реализация состояний проще.

А на будущее рекомендовал бы с автомата Мура перейти на автомат Мили.

Реализован фактически автомат Мили /реализация графа во вложении/. Дело в том, что если состояния вполне однозначны /как на приведенном графе/, то конвертация одного автомата в другой происходит в уме совершенно безболезненно.

Использование флажков типа F1 - тоже не порядок, чем Вам лишняя вершина не угодила?

Это остатки былой "роскоши". Когда установка была абсолютно новой, у нее не только головка /движения "к S23" и "к S24"/ но и вся каретка /движения "вперед" и "назад"/ двигались в обе стороны: был еще флажок F2, который определял, в какую сторону на текущем цикле у нас "вперед" и не было веточки 13-14-0. По мере износа стало все труднее выставлять датчики позиции, поэтому теперь каретка имеет рабочий ход только в одну сторону, флажок F2 канул в прошлое, а F1 пока остался...

[Михайло]

В данном конкретном случае /т.е. однолинейный монограф/ - гонка состояний есть конкуренция двух состояний. Вот если на переходах 9-10 и 10-9 поставить одинаковые условия - будет гонка состояний: на каждом цикле автомат будет переключаться то в 9, то в 10 состояние. Тут же никаких других воздействий нет...

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

Правильнее рассмотреть ситуацию, когда система находится в вершине 9 и стали активны оба перехода 9-10 и 9-12. Вот тут настоящая гонка состояний будет! Если угодно: гонка переходов приводит к гонке состояний. Правда у тебя все же приоритет неявно задан. Чтобы гонки состояний не было в принципе, то нужно на ребре 9-10, например, написать условие "/На позиции и /Конечное". Тогда приоритет отойдет к переходу 9-12.

[Степа]

это не гонки состояний, а глюки графа

Ну в общем-то как ни назови, но это ошибка в алгоритме.

когда система находится в вершине 9 и стали активны оба перехода 9-10 и 9-12. Вот тут настоящая гонка состояний будет!

Не будет. В этом случае если проверка выхода на ребро 9-10 будет раньше, то автомат уйдет по 9-10-12 /по ребру 10-11 можно уйти только по истечении таймера, который будет запущен при проходе ребра 9-10; вполне очевидно, что таймер работает больше одного такта, иначе его бы тут не было; да даже если бы и не было таймера, то тогда ребро 10-11 стало бы безусловным, а выход на безусловное ребро по умолчанию имеет низший приоритет перед условным и поэтому все равно путь лежит по 10-12/.
Если будет раньше проверка выхода на ребро 9-12 - автомат уходит в состояние 12.
А из состояния 12 только один путь - по безусловному ребру в состояние 13... И вернуться с этого пути можно только в одном случае: пока выполняется пауза смены направления /состояние 13/ отвалится датчик "Конечное" /из-за диких люфтов в механике такое вполне возможно/.

[Степа]

При этом заметьте: одно состояние активно в одном цикле программы, другое состояние - в другом цикле. Никакой гонки-то и нет. Хуже, когда в пределах одного цикла один и тот же бит включается и выключается.

Бесцельное переключение из состояния в состояние - нормально???? :amazement:
В монолинейном монографе не выгорит включать и выключать один и тот же бит в пределах одного цикла. Такое может быть или в мультилинейном монографе или в мультиграфе.

[Михайло]

В этом случае если проверка выхода на ребро 9-10 будет раньше, то автомат уйдет по 9-10-12 <...> Если будет раньше проверка выхода на ребро 9-12 - автомат уходит в состояние 12.

Извини, но у тебя на схеме не указан приоритет. Если не рассматривать реализацию графа, то происходит самая настоящая гонка переходов.

[Степа]

Извини, но у тебя на схеме не указан приоритет.

Так он и не нужен. В любом случае на такте отрабатывается одно состояние - это однолинейный автомат, тут нет псевдопараллельности. Поэтому на первом такте - 9, на втором - 10, на третьем - 12. Это если по веточке 9-10-12. Таймер больше времени такта, иначе бы хватило задержки между тактами.

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

[CHANt]

Мили или Мура, а почему не Мили-Мура? Вот пример котла с обвязкой на первой странице топика приводил, там нужно было выставлять различные уставки аналоговому трехходовому клапану при нахождении в той или иной вершине, но при этом условий для перехода не возникало. Т.е. я хочу сказать что, применять ту или иную конкретную модель автомата (или смешанную) решаешь отталкиваясь от технологии. У Степы в нотации проблем с использованием различных автоматов нет, да хоть смешанную. Скелет позволяет. Просто, после компаратора ( к примеру: AB= Сост1, 13) надо добавить действия, до анализа условий перехода на следующую вершину и выполнения команд.

Честно, завидую Вам мужики. Вы вообще не предусматриваете нештатных ситуаций (либо по-минимуму) типа - не пришел конечник. Если что - оператор остановит. У меня не получается так. Каждую внешнюю команду надо контролировать по обратной связи, либо по косвенным признакам. И если что, производить АПВ, либо включать резерв. Операторов нет. Диспетчеру надо сигнализацию, а пока дежурка до объекта доедет может и не один час пройти. Трындец наступит.
А скелет кода схож. Различия только в подходе к выходным действиям. И нумерация вершин числами, в отличии от флагов у Михайло, мне тоже ближе. Мониторить легче.

А вот приоритеты для дуг нужны Степа, особенно когда есть необходимость обеспечивать безопасность в первую очередь. Тут Михайло безусловно прав. Я не сильно понимаю работу данного сварочного агрегата, может здесь действительно явная приоритезация не нужна, но защиты и блокировки должны быть в приоритете.

[Михайло]

А Вы программу посмотрите, Степа выкладывал. Он не показал на графе, но там просто сбрасывается все от нажатия кнопки Стоп и других условий.

[CHANt]

А Вы программу посмотрите, Степа выкладывал. Он не показал на графе, но там просто сбрасывается все от нажатия кнопки Стоп и других условий.

Я ее и посмотрел. :)

[Степа]

У меня не получается так. Каждую внешнюю команду надо контролировать по обратной связи, либо по косвенным признакам. И если что, производить АПВ, либо включать резерв. Операторов нет. Диспетчеру надо сигнализацию, а пока дежурка до объекта доедет может и не один час пройти.

У меня тоже так не всегда получается. Только не всегда алгоритм в автомат выкладывается. Сейчас вот как раз такой объект в стадии заканчивания, алгоритм получился линейный: если случилось условие 1, то выполнить действие 1. И так весь алгоритм...
Вот та установка, от которой граф выложен. Там пять шкафов управления, автоматы только в двух их них /в одном три, в другом два; все пять автоматов одинаковые; было поначалу желание заставить один автомат обрабатывать все установки, так наладчику искать причину ненормальности в работе стало тяжело - тут сэкономили на панелях, поэтому каждую установку обслуживает свой автомат/. Остальные - от текущих условий... Опять же условия работы таковы, что вот в этой установке проще оборвать цикл и пусть оператор разбирается.

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

Может быть Вы и правы... У меня просто еще не было опыта работы со страшными для человека объектами, и, при том, необслуживаемыми. Всегда или оператор под боком или ничего особо опасного, чтобы было критично время срабатывания защиты - ну сработает на пару-другую десятков мс позже, не страшно. Поэтому особо и не заморачивался приоритетами.
Но никто же не мешает как-то пометить приоритетное ребро: их же не должно быть особо много. У вас вот я нашел только одно состояние с четырьмя выходными ребрами - 4. Работа котла. Остальные - три и меньше выходных ребер имеют...

И нумерация вершин числами, в отличии от флагов у Михайло, мне тоже ближе.

От подхода зависит. Если есть желание построить мультилинейный граф /который Михайло предлагает/, то лучше флажками - установлен бит, исполняем состояние. Число флажков равно числу состояний в графе и исполниться могут хоть все вершины разом. А если сделать нумерацию числами, то тогда придется задаваться максимально возможным числом параллельно исполняемых вершин. И тогда могут быть проблемы, если в процессе отработки автомата вдруг понадобится это число увеличить или вдруг не хватит байта под полезные данные - ПЛК не ПК, памятью в гигабайты пока похвастаться не могут, в самом лучшем случае сотни килобайт...

[Михайло]

Степа, памяти хватит, если ее пошукать! Вон у 200-ки области памяти M, V, S - всем хватит.

Кстати, Степан предлагает называть "мой" монограф мультилинейным графом, а обычные графы - монолинейными. Мне как-то больше нравится по-русски называть - многолинейный/однолинейный или многопоточный/однопоточный. Последние варианты наверное будут более правильными, учитывая термин "поток" в компьютерных языках программирования...