DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 09:48

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 15:54 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Смотрите -
http://forum.drakon.su/viewtopic.php?p=100098#p100098

Тема - " ИС Дракон и программирование конечных автоматов".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 15:55 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Денис Шубенков писал(а):
Согласен.
Пока возврат управления надо делать вручную. Т.е. самому побеспокоиться чтобы произошел возврат управления после запуска паузы (таймера) и обработать условие по окончанию работы паузы (таймера).

Не нужно это терпеть.
Во-первых, программа с ручным запуском и проверкой таймеров ну ничем не лучше простого ST кода. Сейчас тов. Тышов считает, что "ИС Дракон" всех устраивает.

Во-вторых, возможно, в иконе паузы можно записать что-то в духе:
Код:
ton1(IN := TRUE, PT := T#5s);
IF NOT ton1.Q THEN RETURN; END_IF;

Тогда нужно будет предварительное действие (сброс таймера ton1(IN:=FALSE) ), но два этих действия "подготовка к паузе" и "пауза" всяко лучше "полностью ручной работы с таймером".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 15:58 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
LKom писал(а):
Тема - " ИС Дракон и программирование конечных автоматов".

А где тема "паузы в конечных автоматах при использовании ИС Дракон"?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 19:51 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Парадокс применения таймеров тон тоф ТП заключается в том что икона управления таймером должна находиться всегда на главном маршруте. А вторая часть может находиться где угодно. Т.е таймер должен состоять из двух всегда связанных икон. Если икона таймера находится вне главного маршрута то блок работает не корректно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 20:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
А_МУР писал(а):
Парадокс применения таймеров тон тоф ТП заключается в том что икона управления таймером должна находиться всегда на главном маршруте. А вторая часть может находиться где угодно. Т.е таймер должен состоять из двух всегда связанных икон. Если икона таймера находится вне главного маршрута то блок работает не корректно.

Пожалуйста, Алексей, будьте добры, объясните вашу мысль подробно с помощью дракон-схемы.
А то ваша мысль непонятна.
Я не смог понять. А хотелось бы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 20:36 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
А_МУР писал(а):
Парадокс применения таймеров тон тоф ТП заключается в том что икона управления таймером должна находиться всегда на главном маршруте. А вторая часть может находиться где угодно. Т.е таймер должен состоять из двух всегда связанных икон. Если икона таймера находится вне главного маршрута то блок работает не корректно.

Если честно, я тоже не понял, но, скорее, звучит как ошибка ИС Дракон, ведь с точки зрения самого языка разницы между главным и побочным маршрутами нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 21:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Ситников писал(а):
с точки зрения самого языка разницы между главным и побочным маршрутами нет.

Вы правы, никакой разницы конечно нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 22:57 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Добрый вечер Уважаемые Коллеги!
Сегодня не буду вдаваться в подробности по поводу конфузов с маршрутами и таймерами (а кроме этого и с многими другими эффектами, к которым приводят маршруты)
Сильно устал с командировки и расскажу про ТАЙМЕРЫ, завтра если будет интересно (просто напомните) вернемся к вопросу маршрутов

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

Итак о таймерах:
Таймер это механизм, который запускается не потому он ТАКОЙ красивый, и не потому что стоит на маршруте программы, а потому что на вход IN пришла ИСТИНА
ОТ КУДА пришла эта ИСТИНА или ЛОЖЬ? Не просто по МАРШРУТУ упало
ДОПУСТИМ
Если есть УСЛОВИЕ - то ПУСК ТАЙМЕРА это ДА, а СТОП ТАЙМЕРА это НЕТ. для пояснения картинка ниже
Тогда таймер всегда становиться в УДЕЛ и все становиться на свои места


Вложения:
Фрагмент.jpg
Фрагмент.jpg [ 78.34 КБ | Просмотров: 15692 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:05 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
КАРТИНКА- это моя мысль о том как должен выглядеть ТАЙМЕР в Дракон схеме, дополнительная икона это часть только для иконы ТАЙМЕР и отдельно использоваться не может
НЕ ЗАБЫВАЙТЕ - МАРШРУТ ЭТО ПРОСТО ПРЯДОК ВЫПОЛНЕНИЯ
На практике приходится таймер ставить выше условия, и копировать на IN все то, что написано в условии, тогда таймер работает, как положено.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:24 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
А_МУР писал(а):
КАРТИНКА- это моя мысль о том как должен выглядеть ТАЙМЕР в Дракон схеме, дополнительная икона это часть только для иконы ТАЙМЕР и отдельно использоваться не может


По-моему, проблема в том, что вы пытаетесь использовать Дракон как 1-в-1 программу на ST.

Можете пояснить какую задачу решает "таймер" тут?
"Запуск таймера", "проверка Q" это весьма низкоуровневые понятия.
Я бы сказал, это "птичий язык".
Слова "давление > 150" -- вполне понятны.
Слова "дождаться пока давление упадёт ниже 150, а потом подождать ещё 5 секунд" тоже понятны. По-моему, как раз в этой области у Дракона наибольшие шансы сделать программы ПЛК понятнее.

А вот TOF таймер и его Q это всё же не те слова, при взгляде на которые сходу понятен алгоритм.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:26 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Это пример таймер может быть любой


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:29 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
что ST, С, и тд все работает примерно одинаково, факт один таймер включается по изменению переменой лил условию


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:30 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
тема называется: Дракон и ПЛК


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 23:35 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
А_МУР писал(а):
что ST, С, и тд все работает примерно одинаково, факт один таймер включается по изменению переменой лил условию

ST и C таймеры это средства для достижения какой-то цели, а не сама цель.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 08:14 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Владимир Ситников писал(а):
А_МУР писал(а):
что ST, С, и тд все работает примерно одинаково, факт один таймер включается по изменению переменой лил условию

ST и C таймеры это средства для достижения какой-то цели, а не сама цель.

Даже спорить на тему целей не буду, интересен только практический результат и опыт


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 10:16 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
А_МУР писал(а):
Даже спорить на тему целей не буду, интересен только практический результат и опыт

А с практической точки зрения для чего в упомянутом примере используется TOF(давления нагнетания)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 19:18 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Ситников писал(а):
По-моему, нужно делать так, чтобы сам Дракон редактор понимал где должен быть этот самый возврат управления.
Тогда ему надо отдельно объяснять, что вот это есть технологическая программа, запускаемая раз в цикл, а вот это есть автономная программа.
Пока такого различия в языке нет.
А "куда возвращаться" - сильно от этого зависит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 19:42 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
А "куда возвращаться" - сильно от этого зависит.

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

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

В контексте "исполнительного механизма" всё довольно однозначно. Ему говорят: "шуруй", он идёт по алгоритму. И ему вообще без разницы где там цикл ПЛК, а где нет. Его пнули -- он продолжил выполнение, поработал немного, и снова приостановился.

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

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

Иными словами, автомат, скомпилированный из Дракон-схемы можно будет использовать в ПЛК коде по своему усмотрению.
В простейшем случае -- вызывать 1 раз в каждом цикле ПЛК. Если задача редкая, можно и реже вызывать. Но самой среде об этом (о самом цикле ПЛК) ничего знать и не нужно. Среде нужно знать в каких точках должна быть приостановка алгоритма.

В "обычном" коде, для эмуляции такого поведения используют "switch state_var case 0:... case 1:..." Как раз в этом плане запись алгоритма в виде квадратиков гораздо понятнее, чем switch case.

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

Ну, если приводить аналогию с CoDeSys, то там вообще есть понятие "задач". Когда объявляешь, что "хочу, чтобы такая-то программа выполнялась раз в секунду". И CoDeSys планирует выполнение задач.
Хочешь -- настраиваешь задачи.
Хочешь -- не настраиваешь, а сам вызываешь всё из PLC_PRG.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 21:59 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Ситников писал(а):
от того, когда будет выполняться автомат не зависит способ его компиляции.
В случае автономной программы паузу можно реализовать простым циклом ожидания, например.
Хотя это и извращение, но теоретических препятствий нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Октябрь, 2017 23:28 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
Владимир Ситников писал(а):
от того, когда будет выполняться автомат не зависит способ его компиляции.
В случае автономной программы паузу можно реализовать простым циклом ожидания, например.
Хотя это и извращение, но теоретических препятствий нет.

Вы о том, что от среды выполнения может зависеть то, в какую именно форму должны компилироваться паузы?
Да, под Arduino паузы делаются одним образом (busywait, delay), под МЭК 61131 другим (запуском на следующем цикле ПЛК). Да, тут я полностью согласен.
Но это прямо что-то кардинально меняет?
По крайней мере, на "куда возвращаться" это никак не влияет.

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

Поэтому:
1) Да, от среды исполнения может зависеть как именно реализуются паузы
2) Как автомат получит управление в следующий раз, он должен продолжить выполнение с места, где остановился. Либо продолжить паузу, либо сдвинуться дальше, если время прошло. Это, вроде как, не зависит ни от языка, ни от среды выполнения.
3) Вариант "автомат возвращает управление" универсален. Если уж очень нужны будут паузы в виде "тупых циклов" (Arduino?), то их тривиально можно прикрутить во внешнем вызывающем коде. При этом, в самой Дракон-схеме ничего меняться не будет.
4) Правила "возврата управления" должны быть явно видны из рисунка. Например, если уж решили, что "на паузах возврат управления", то это должно автоматически происходить. Не должно оставаться лазейки для ошибок типа "где-то там внутри иконы забыли написать return".
5) Более того, в генерируемом автомате должна генерироваться и защита от зацикливания. Иными словами, если он прокрутился более N циклов и не вернул управление, то что-то должно происходить. Например: возврат управления (вызывающая программа посмотрит, увидит зацикливание и, например, перезапустит), или передача управления в специальную ветку "обработки зацикливания".

Что именно должно быть маркером "возврата управления" вопрос наполовину решённый.
Почти наверняка паузы должны возвращать. Тут возражений не было, и были примеры, когда такое поведение упрощало понимание алгоритмов в Дракон-виде.

"Цикл ожидания" -- тоже должен. Но там нюанс: "цикл ожидания с нулевой задержкой" визуально невозможно отличить от repeat until (в котором не нужно возвращать управление на каждой итерации). Как поступать в этом случае -- неясно. Например, можно возвращать управление на любых обратных прыжках и каким-то образом (каким?) позволить пользователю указать "век_воли_невидать_это_repeat_until_цикл_быстрый_не_надо_возвращать_упраление" для случая, если реально сделан repeat until цикл в котором все итерации нужно сделать в рамках одного действия автомата.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


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

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


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB