DRAKON.SU https://forum.drakon.su/ |
|
Проблема с отображением алгоритмов реального времени https://forum.drakon.su/viewtopic.php?f=78&t=6068 |
Страница 2 из 3 |
Автор: | А_МУР [ Вторник, 03 Октябрь, 2017 11:58 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
TAU писал(а): А_МУР писал(а): Писал функциональный блок управления насосами под СПК 107, использовал таймеры задержки включения и выключения. В дракон схеме эти таймеры пришлось компоновать в отдельную подпрограмму. На самом деле таймеры представляют из себя след схему Икона запуска таймера соединена с вопросом отсчитал таймер время уставки или нет Если да делаем нужное действие и идем дальше, если нет идем дальше Все работает на железе Очень интересно! А можно посмотреть на примеры? Заранее спасибо! Можно в личку. И еще. Все, что сделано графически и работает "на железе", лично мне весьма интересно. Может, создадим раздел здесь, на форуме, где систематизируем примеры? Буду рад ответить на все вопросы в почте a_muravitsky@okbamur3.ru |
Автор: | Владимир Паронджанов [ Вторник, 03 Октябрь, 2017 12:00 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
А_МУР писал(а): Здравствуйте Уважаемые Коллеги! Выкладываю ................. Цитата: Вложения: узел насосов подпитки.drt [7.63 КБ] Алексей, желательно выкладывать картинку дракон-схемы, например в формате .png Чтобы все могли видеть без скачивания. Спасибо |
Автор: | TAU [ Среда, 04 Октябрь, 2017 01:21 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
А_МУР писал(а): Выкладываю... Что значит "Q таймера"? |
Автор: | А_МУР [ Среда, 04 Октябрь, 2017 12:01 ] | ||
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени | ||
TAU писал(а): А_МУР писал(а): Выкладываю... Что значит "Q таймера"? Здравствуйте Уважаемые Коллеги! Предлагаю разобраться с временем на "полевом" уровне! АКСИОМА: в любом процессоре (контролере) есть "тактовый генератор" или "тактовый таймер", который выдает в" программное пространство" -импульсы или "ТИКИ", Запускается ОН, как только подано питание на процессор (контроллер), и работает не зависимо от процессов в самом процессоре. ЭТО СДЕЛАНО НА ФИЗИЧЕСКОМ УРОВНЕ И ИЗМЕНИТЬ МЫ ЭТОГО НЕ МОЖЕМ! ВЫВОД ДЛЯ ДРАКОНА: ИСПОЛЬЗОВАТЬ ИКОНУ "ПУСК ТАЙМЕРА" НЕ ИМЕЕТ СМЫСЛА Т.К. ТАЙМЕР УЖЕ ЗАПУЩЕН НА ФИЗИЧЕСКОМ УРОВНЕ! ОСТАЕТСЯ ТОЛЬКО СЧИТАТЬ "ТИКИ" В НУЖНОМ МЕСТЕ АЛГОРИТМА ОБЩИЙ ВИД ТАЙМЕРА , НА ЯЗЫКЕ ДРАКОН
|
Автор: | А_МУР [ Среда, 04 Октябрь, 2017 12:06 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Чуть позже если кому-то будет интересно напишу: 1) про основные типовые ТАЙМЕРЫ, 2) про РЕАЛЬНОЕ ВРЕМЯ от куда оно берется, и как выглядит, как обрабатывается внутри программы. 3) свое видение по применению алгоритмов ВРЕМЕНИ в ДРАКОНЕ |
Автор: | Владимир Ситников [ Среда, 04 Октябрь, 2017 12:21 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
TAU писал(а): Что значит "Q таймера"? Q это "флаг сработки таймера". TON это стандартный таймер в МЭК61131 (см http://plc24.ru/tajmery-v-codesys/ ) IN это его вход, а Q выход. |
Автор: | А_МУР [ Среда, 04 Октябрь, 2017 12:34 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Ситников писал(а): TAU писал(а): Что значит "Q таймера"? Q это "флаг сработки таймера". TON это стандартный таймер в МЭК61131 (см http://plc24.ru/tajmery-v-codesys/ ) IN это его вход, а Q выход. Владимир прав, есть еще вход уставки или задания таймера, НО как я понял необходимо объяснить суть работы таймеров задержки включения и выключения! |
Автор: | Владимир Ситников [ Четверг, 05 Октябрь, 2017 17:25 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
А_МУР писал(а): ВЫВОД ДЛЯ ДРАКОНА: ИСПОЛЬЗОВАТЬ ИКОНУ "ПУСК ТАЙМЕРА" НЕ ИМЕЕТ СМЫСЛА Т.К. ТАЙМЕР УЖЕ ЗАПУЩЕН НА ФИЗИЧЕСКОМ УРОВНЕ! ОСТАЕТСЯ ТОЛЬКО СЧИТАТЬ "ТИКИ" В НУЖНОМ МЕСТЕ АЛГОРИТМА Тут вы путаете "часы" и "TON-таймер". Иконы "пуск таймера", "синхронизатор", "пауза" (стр 207 http://drakon.su/_media/01._parondzhano ... oritmy.pdf ) решают вполне конкретную задачу "открыть заслонку через 1 минуту после предыдущего шага" Иными словами, "таймер" в смысле Дракона это просто секундомер. Его можно сбрасывать и его показания постоянно бегут вперёд. В МЭК61131 это был бы такой блок: Код: VAR_INPUT RESET : BOOL; END_VAR VAR_OUTPUT ET : TIME; END_VAR Вы же хотите под словом "таймер" получить TON, TOF, TP таймеры из 61131. И тут нюанс. В вашем примере (Дракон-схемы для насосов) как раз неочевидно что значит "запуск таймера" и потом сразу "сравнение Q". В обычном цикле ПЛК программа выполняется каждую миллисекунду с начала и до конца. Иными словами, вы считаете, что программа будет многократно (на протяжении 10и секунд!) проходиться по такой ветке: "главная" - "есть пуск? да" - "насос1 работает? да" - "реле давление включено? нет" - "запуск таймера ton1" - "Q таймера TON? нет " - "завершение". При этом, "запуск таймера", на самом деле, это не сброс секундомера каждый раз, а именно обновление состояния МЭК таймера. Он не сбрасывается, а просто вызывается и обновляет состояние (с учётом прошедшего времени). Я обсуждал подобный вопрос с Владимиром Паронджановым, и он говорил, что в ЛА алгоритмы работали с вытесняющей многозадачностью. Т.е. алгоритм составляем в духе "хоть циклы, хоть ожидания, хоть что", а уже операционна система периодически переключает выполнение на другую задачу/процесс. Поэтому там и использовались штуки в духе "включить зелёный", "пауза 2 минуты", "выключить зелёный; включить жёлтый" ... Но, к сожалению, я пока сам не знаю есть ли удобный способ записи ПЛК-программ на Драконе. К обычным ПЛК Дракон как-то не клеится, т.к. с одной стороны хотелось бы не привязывать Дракон-схему к "циклу ПЛК" (ну иметь возможность ставить паузы и циклы ожидания прямо в нужном месте алгоритма), а с другой, от цикла ПЛК никуда не уйдёшь, ведь чтение входов и запись выходов к нему привязана в любом случае. PS У вас ветки "запуск насоса 1" , "запуск насоса 2" дублируют основную ветку "главная". Выглядит, конечно, сурово. Такую схему для 3-4 насосов рисовать вообще печально было бы. |
Автор: | Владимир Паронджанов [ Четверг, 05 Октябрь, 2017 21:13 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Ситников писал(а): к сожалению, я пока сам не знаю есть ли удобный способ записи ПЛК-программ на Драконе. К обычным ПЛК Дракон как-то не клеится Я попросил Сергея Ефанова из Липецка высказать свое мнение по данному вопросу. Вот его ответ: Цитата: Ньюансы применения Дракона в ПЛК мне неведомы, я ПЛК не программировал. Если есть возможность загрузить в ПЛК программу на Си - то не вижу препятствий для применения Дракона. Приложенная иллюстрация одного из вариантов выполнения задержек вполне адекватно будет работать и в ПЛК. Он отличается простотой и экономным расходованием ресурсов. Но это, ни в коем случае - не единственно возможный вариант. Иллюстрация Вложение:
|
Автор: | Владимир Ситников [ Четверг, 05 Октябрь, 2017 23:21 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Паронджанов писал(а): Я попросил Сергея Ефанова из Липецка высказать свое мнение по данному вопросу. Вот его ответ: Цитата: Ньюансы применения Дракона в ПЛК мне неведомы, я ПЛК не программировал. Поясню смысл "ПЛК". ПЛК это компьютер, у которого есть: 1) Входы. Грубо говоря, значения подключенных датчиков. 2) Выходы. Грубо говоря, команды на управление внешними механизмами, замыкание/размыкание реле. 3) Связь с другими модулями (например, может быть внешний двигатель, которому ПЛК периодически передаёт значение скорости, а от него получает информацию о состоянии) Так вот: прикладной код должен иметь возможность читать значения входов и изменять состояние выходов. Но возникает вопрос: в какой момент значения входов должны обновляться? Например, если у ПЛК 10 выходов, и в программе мы записали единицу в каждый из выходов. Должны ли они включиться одновременно, или допутима задержка? Если программа работает в вытесняющей многозадачности, то может оказаться, что выходы будут активироваться по одному. Это будет запутывать, особенно неподготовленных программистов. Гораздо проще составлять программу, если подразумевать, что "мир остановился в момент выполнения программы". Как раз в в МЭК61131 такой подход и выбран. Попросту говоря, это вытесняющая многозадачность, где возврат управления происходит лишь при завершении прикладного кода. Шаг1) ПЛК опрашивает состояние входов Шаг2) Выполняется пользовательская программа. При этом, программе запрещено зацикливаться, и выполниться одна должна максимально быстро. В момент выполнения пользовательского кода состояние входов-выходов не изменяется. Т.е. пользовательский код работает с переменными=-копиями. Шаг3) ПЛК выполняет служебные задачи на протяжении 1мс. Выполняется обработка сетевого взаимодействия и т.п. Шаг4) По результатам работы Ш2 обновляются значения выходов Шаг5) переход к шагу 1 На самом деле, на служебные задачи отводится не 1мс, а (1мс-длительность_шага_2). Таким образом обеспечивается то, что значения входов обновляются каждую миллисекунду. Но при этом, если прикладной код слишком долго не возвращает управление, то система перезагружается. Как правило, более 2-5 секунд это уже перезагрузка. То, что пишет Сергей Ефанов подходит для игрушечного примера, а к реальной задаче (с обработкой сетевого взаимодействия) уже не применить. Проблема "Дракон-ПЛК" звучит так: 1) С точки зрения Дракона, ожидание таймера это "цикл ждать". Если сделать "цикл" в лоб (без возврата управления), то это приведёт к перезагрузке. 2) Если на уровне Дракон компилятора компилировать икону "цикл ждать" так, чтобы она таки возвращала управление в систему, то возникает ситуация, когда между действиями обновляются значения входов-выходов. Скажем, если возврат управления (т.е. обновление входов-выходов) может произойти в момент иконы ожидания, то может ли этот возврат управления в ОС произойти в момент других икон? 3) Если разрешить возврат управления после каждой иконы, то понимать программу, наверное, будет сложнее, ведь получается, что состояние входов-выходов сможет измениться в каждый момент 4) Вообще говоря, входов у ПЛК несколько. Например, у меня ПЛК получает сигналы от кнопок, датчиков движения, и в зависимости от них включает-выключает свет. Одна из простейших задач -- распознавание одинарного и двойного нажатия. С логической точки зрения это несложно: если обнаружено срабатывание кнопки, то запускаем таймер и в цикле ждать ждём (где-то 0.5сек) придёт ли второй. Если второго не последовало, значит было одинарное нажатие. Если пришло, значит было двойное нажатие. Тут знакомый нам "цикл ждать", и, значит, обработка кнопок должна быть в отдельных Дракон схемах (в отдельных процессах). Ну и собственно возникают вопросы "в каком порядке должны обрабатываться эти параллельные схемы", "как должны передаваться данные от одного процесса к другому" и т.п. Если присмотреться к схеме А_МУР (большой, про насосы), то видно, что она сделана с расчётом на "возврат управления" происходит по иконе "Конец". Из-за этого в схеме возникают нехорошие моменты: a) код состояния=3, код состояния=4 и т.п. В соседних темах обсуждают "солнечный зайчик", который ходит по схеме и показывает где находимся, а тут глобальная переменная, которая влияет на выполнение всей схемы. b) уже упомянутая связка "запуск таймера"-"проверка Q таймера". Логичнее было бы задействовать "циклы ждать" или что-то подобное PS. Кстати, может быть неплохой идеей вообще созвониться. Например, https://hangouts.google.com/ и YouTube live позволяют созваниваться со звуком/видео и записывать разговоры. |
Автор: | Владимир Паронджанов [ Пятница, 06 Октябрь, 2017 08:10 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Сергей Ефанов писал(а): Если есть возможность загрузить в ПЛК программу на Си - то не вижу препятствий для применения Дракона. Владимир, что вы думаете насчет Си. Есть возможность?
|
Автор: | Владимир Ситников [ Пятница, 06 Октябрь, 2017 10:46 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Паронджанов писал(а): Сергей Ефанов писал(а): Если есть возможность загрузить в ПЛК программу на Си - то не вижу препятствий для применения Дракона. Владимир, что вы думаете насчет Си. Есть возможность?Во-первых, часто возможности нет. Есть огромная потребность программировать контроллеры для канализационно насосных станций, котельных, управлению отоплением, станками и т.п. При этом, программисты там, очевидно, не экстра-класса. Они могут составить программу из логических операций и предусмотреть разные аварийные ситуации. Но вот написать программу на Си, понять адресную арифметику, написать драйвер сетевого обмена могут единицы. Поэтому индустрия и пришла к МЭК61131 -- стандарту программирования микроконтроллеров, в котором оставлено только самое необходимое и "сломать контроллер плохой программой" там гораздо сложнее, чем при использовании программ на Си. Например, контроллеры ОВЕН программировать на Си невозможно. Контроллеры МЗТА де-факто возможно, но никто так не делает. Во-вторых, даже, если бы и была возможность программировать ПЛК на Си (бывают и такие, они гораздо менее распространены), то препятствия к применению Дракона всё равно есть. И они те же самые, что я описал выше -- отсутствие вытесняющей многозадачности. Иными словами, если в прикладной программе написан "цикл ждать 5 секунд", то эти 5 секунд контроллер должен не просто стоять, а обслуживать системные задачи (сетевой обмен). Сергей что, предлагает написать(купить) ОСРВ? |
Автор: | Владимир Паронджанов [ Пятница, 06 Октябрь, 2017 12:38 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Сергей Ефанов попросил меня выложить его НОВОЕ замечание. Цитирую все письмо: Цитата: Re: Другой вопрос Ефанов Сергей <efanov@lipetsk.ru> Кому: Паронджанов Владимир сегодня, 12:23 Здравствуйте, Владимир Данилович. Заглянул на форум, почитал. Идею там не поняли, нужно пояснить. Разместите, пожалуйста, там мою реплику: Владимир Ситников писал(а): То, что пишет Сергей Ефанов подходит для игрушечного примера, а к реальной задаче (с обработкой сетевого взаимодействия) уже не применить. Это неверное утверждение. Очевидно, пояснения в иконе 15 было недостаточно. Суть вот в чём. ИС Дракон имеет 3 режима генерации кода: 1. Схема "Силуэт" кодируется в обычную функцию, вход в которою происходит через икону "Заголовок", а выход - через икону "Завершение". Если в такой функции мы нарисуем цикл с ожиданием в 10 секунд - то возврат из такой функции произойдёт через 10 секунд. Что недопустимо. 2. Схема "Силуэт" кодируется в конечный автомат, выполненный на переключателе "switch". В самом начале функции записан оператор "switch(ss)",код каждой ветки начинается с "case xx: ", а заканчивается "break;". "ss"-целочисленная переменная состояния. Так что, когда алгоритм доходит до конца ветки - происходит выход из функции, а вход в следующую ветку происходит при следующем вызове функции. Переход на ветке в её НАЧАЛО - так-же приводит к выходу из функции. Так работает ветка "Задержка" в представленном ранее примере. Автомат множество раз пройдёт по этой ветке, каждый раз возвращая управление в основную программу через пару микросекунд, а через 10 сек — произойдёт переход на следующую ветку. 3. Схема "Силуэт" кодируется в конечный автомат, в котором каждое состояние описано отдельной функцией, а в качестве переменной состояния использован указатель на функцию. Этот способ кодирования позволяет сделать очень быстрый автомат, время переключения между состояниями которого минимально, и независимо от общего числа состояний. Таким образом, приведённый ранее пример не игрушечный, а вполне реальный. Повторно выкладываю дракон-схему Сергея Ефанова: Вложение:
|
Автор: | Владимир Ситников [ Пятница, 06 Октябрь, 2017 13:31 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Паронджанов писал(а): Заглянул на форум, почитал. Идею там не поняли, нужно пояснить. А теперь читаем моё сообщение про <<Проблема "Дракон-ПЛК" звучит так:>> и видим, что я и Сергей говорим об одном и том же: 1) Если возвращать управление в ОС только в конце алгоритма -- всё повиснет -- тут "пункт 1 Сергея" и мой прямо совпадают 2) В своём втором пункте Сергей говорит "а давайте возвращать управление в ОС после каждой Дракон-иконы". У меня вариант "возврат управления после каждой иконы" это только 3-ий вариант. У меня 2-ой пункт более щадящий -- возвращать управление в специальных иконах (например, в цикле ждать, в иконе паузы и т.п.) Да возврат управления на каждой иконе, якобы, сработает, но на самом деле нет: 2.1) В реальном ПЛК возврат управления стОит 1мс (это как минимум. А иногда и больше настраивают). Я же писал, что там кооперативная многозадачность, и ОС вызывает прикладной код ровно(не чаще чем) каждую миллисекунду. Если Дракон-код будет останавливаться на каждой иконе ("возвращать управление в ОС из скомпилированной Дракон фукнции"), то это неоправданно увеличит время работы кода, увеличит время реакции системы и т.п. 2,2) Если "возвращать управление в ОС" (выходить из скомпилированной функции после каждой иконы), то ОС при этом обновит состояние входов-выходов ПЛК. В итоге, может дойти до абсурда: две подряд иконы "насос работает?" могут вернуть разный результат. Неудобно, знаете ли, писать программу, когда каждая переменная может измениться в любой момент времени. 2.3) Нет ответа на вопрос как компилировать "параллельные процессы" (ну, несколько Дракон-схем, работающих в параллель). Их-то в каком порядке выполнять? Ну и в самом Драконе, похоже, отсутствуют понятия по передаче сообщений/значений между процессами. Владимир Паронджанов писал(а): Этот способ кодирования позволяет сделать очень быстрый автомат, время переключения между состояниями которого минимально, и независимо от общего числа состояний. Сам автомат-то быстрый, но толку от этого ноль, ведь ОС вызывает прикладной код не чаще 1 раза в миллисекунду. Сделали 10 икон в Дракон схеме -- ну и не сможет эта схема выполниться быстрее 10мс. Сделали 100 икон -- получай 100мс на обработку программы. |
Автор: | Владимир Паронджанов [ Пятница, 06 Октябрь, 2017 15:14 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Ситников писал(а): В своём втором пункте Сергей Ефанов говорит "а давайте возвращать управление в ОС после каждой Дракон-иконы". Ответ Сергея Ефанова: Цитата: Не говорил я ТАКОГО!
Управление возвращается не после каждой ИКОНЫ, а после каждой ВЕТКИ. Этот нюанс меняет ситуацию от абсудной до нормальной. Соответственно, рассуждения Владимира Ситникова 2.1 и 2.2 - тоже неверны. 2.3. Никаких специальных средств на эту тему в Драконе нет. Собственно, когда Вы пишите программу на ПЛК, то сетевые и прочие взаимодействия Вы осуществляете средствами, представленными Вам самим ПЛК. Точно также можно обращаться к ним и из программы на Драконе. Я не программирую ПЛК, делаю свои контроллеры, схемы которых адекватны задаче. Общая идеология программ в этих контроллерах - весьма близка к ПЛК. Тот же главный цикл, опрос входов в начале, запись в выходы - в конце цикла. Только без огромных таблиц глобально доступных переменных. Обычно "крутится" по 30-50 автоматов, нарисованных на Драконе. Вызываются все в главном цикле по очереди. Порядок вызовов значения не имеет. Главное - все автоматы должны быть вызваны в КАЖДОМ цикле, и за один вызов любой автомат может совершить НЕ БОЛЕЕ ОДНОГО перехода. Средства их взаимодействия - несколько ОЧЕНЬ простых функций. |
Автор: | Владимир Ситников [ Пятница, 06 Октябрь, 2017 16:20 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Паронджанов писал(а): Управление возвращается не после каждой ИКОНЫ, а после каждой ВЕТКИ. После каждой ветки? Шикарно Тогда программа зависнет на первом же "цикле ждать". Например, икона 16 "есть команда пуск?"-- "нет" Видно, что стрелка из "нет" приходит снова в 16-ую икону. Внимание, вопрос: каким образом система не подвиснет на 16-ой иконе, ведь управление возвращается "в конце ветки"? Ну и, кстати, связывать "возврат управления" с концом ветки, это по-моему, спорное утверждение, т.к. зачастую разбивка на ветки делается логически (ну, чтобы на экране хорошо выглядело), а отождествлять "конец ветки" и "возврат управления из автомата" это несколько странно. |
Автор: | TAU [ Суббота, 07 Октябрь, 2017 14:51 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Ситников писал(а): Владимир Паронджанов писал(а): Управление возвращается не после каждой ИКОНЫ, а после каждой ВЕТКИ. После каждой ветки? Шикарно Тогда программа зависнет на первом же "цикле ждать" Слушайте, ну вам же русским по белому написали - человек успешно программирует на практике и у него все функционирует. Заняться, что ли, больше нечем? |
Автор: | Владимир Ситников [ Суббота, 07 Октябрь, 2017 15:44 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
TAU писал(а): Заняться, что ли, больше нечем? По делу есть что-нибудь? |
Автор: | Владимир Ситников [ Суббота, 07 Октябрь, 2017 15:55 ] |
Заголовок сообщения: | Re: Проблема с отображением алгоритмов реального времени |
Владимир Ситников писал(а): Внимание, вопрос: каким образом система не подвиснет на 16-ой иконе, ведь управление возвращается "в конце ветки"? Увидел фразу, отвечающую на этот вопрос: Сергей Ефанов писал(а): Переход на ветке в её НАЧАЛО - так-же приводит к выходу из функции. Раньше, я почему-то считал, что речь о переходе через "Адрес", но, судя по всему, считается и просто стрелочка, смотрящая наверх. |
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |