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

Монограф

Модератор: специалисты по PLC


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 31 окт 2010, 09:12

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 31 окт 2010, 09:33

Не совсем так, на Си возможностей больше чем на МЭКе,
Изображение
--------------------------------------------------------------------------------------------
"Почти все начальники - дилетанты." © цитата из поста hell_boy )))


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 31 окт 2010, 10:36

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 31 окт 2010, 18:32

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 01 ноя 2010, 04:20

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


Бондарев Михаил
почётный участник форума
почётный участник форума
Сообщения: 945
Зарегистрирован: 25 июл 2008, 22:23
Ф.И.О.: Бондарев Михаил Владимирович
Поблагодарили: 1 раз

Re: Примеры подхода "Монограф"

Сообщение Бондарев Михаил » 01 ноя 2010, 07:21

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


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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 01 ноя 2010, 17:13

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

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

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

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

Бондарев Михаил писал(а):а как насчет напрямую из Паскаля/Си скомпиировать и залить?

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

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

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

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 01 ноя 2010, 18:30

Степа писал(а):Ребро со свободным переходом

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

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

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

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 01 ноя 2010, 18:49

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

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

Степа писал(а):Теперь по поводу моего подхода...

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 01 ноя 2010, 18:53

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

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

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

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 01 ноя 2010, 19:03

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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 01 ноя 2010, 19:57

Михайло писал(а):Лучше: "Ребро с безусловным переходом".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 01 ноя 2010, 21:13

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

А прямо в микровине проектик, если не сложно. Интересует-заход в состояние, выход из него, переход в следующее - скелет.
--------------------------------------------------------------------------------------------
"Почти все начальники - дилетанты." © цитата из поста hell_boy )))


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 02 ноя 2010, 04:41

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

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

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

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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 02 ноя 2010, 10:51

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

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

Михайло писал(а):У Степы, я знаю, раздвоение запрещено...

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

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

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

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

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

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

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

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 02 ноя 2010, 15:52

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

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

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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 02 ноя 2010, 16:34

Михайло писал(а):это не гонки состояний, а глюки графа

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

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

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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 02 ноя 2010, 16:40

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 02 ноя 2010, 17:48

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

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


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 02 ноя 2010, 18:39

Михайло писал(а):Извини, но у тебя на схеме не указан приоритет.

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

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 02 ноя 2010, 23:30

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

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 03 ноя 2010, 05:18

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

Аватара пользователя

CHANt
эксперт
эксперт
Сообщения: 1247
Зарегистрирован: 25 июл 2008, 09:25
Ф.И.О.: Гринев Эдуард Владимирович
Откуда: Оренбург
Благодарил (а): 12 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение CHANt » 03 ноя 2010, 06:09

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

Я ее и посмотрел. :)
--------------------------------------------------------------------------------------------
"Почти все начальники - дилетанты." © цитата из поста hell_boy )))


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Примеры подхода "Монограф"

Сообщение Степа » 03 ноя 2010, 09:52

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

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

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

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

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2228
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Примеры подхода "Монограф"

Сообщение Михайло » 03 ноя 2010, 14:48

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

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


Вернуться в «Обсуждение F.A.Q. по PLC»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей