DRAKON.SU

Текущее время: Воскресенье, 07 Март, 2021 01:58

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




Начать новую тему Ответить на тему  [ Сообщений: 22 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 03 Февраль, 2015 14:37 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Добрый день, пользователи и знатоки ЯП Дракон!

После очень долгого перерыва решил вернуться к теме использование Дракона для проектирования алгоритмов АСУ ТП. Сделал схему для довольно простого агрегата.
На схеме явно есть ошибки и глупости.
Подскажите, пожалуйста, где и почему?


Вложения:
double-hopper-2.png
double-hopper-2.png [ 68.3 КБ | Просмотров: 13547 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Февраль, 2015 22:05 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Раз алгоритм относится к АСУ ТП, предположу, что программа, созданная на его основе, будет крутиться на ПЛК. А значит, то что изображено на схеме будет выполняться в течении одного цикла работы ПЛК.

т. е.

В начале цикла передаётся управление на икону Начало, а в конце цикла осуществляется выход через икону Конец. И так постоянно.

Тогда:

1.
Что делать если нет ни команды СТАРТ, ни команды СТОП?

2.
Действия ОТКРЫТЬ, ЗАКРЫТЬ задвижки (клапана ?) будут происходить одновременно в каждом цикле. Либо выполнение программы будет виснуть на иконах Ждать.

3.
Открываем EV01, а проверяем статус EV02. Так должно быть?

4.
Команды СТАРТ, СТОП, а также аварии (ошибки) задвижек могут произойти в произвольный момент времени?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 08:40 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Вот здесь, например, алгоритм открытия задвижки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 12:19 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Эдуард, спасибо. Буду думать.

Что смущает. Вот есть алгоритм работы агрегаты, который можно реализовать как на ПЛК, так и другими средствами (например ПК + скрипотвый язык). Разве Д-схема зависит от "исполнителя" (средств реализации)? Мне казалось, что не должно зависеть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 12:46 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
hothing писал(а):
Разве Д-схема зависит от "исполнителя" (средств реализации)? Мне казалось, что не должно зависеть.
Должно. Потому что одно дело, когда вы пишете программу управления ЦЕЛИКОМ (на ПК, например, или на голом микроконтроллере), где сами реализуете рабочий цикл, и совершенно другое, когда встраиваете как часть в уже имеющееся ПО (в данном случае системное ПО ПЛК).
Разные уровни программирования, разные интерфейсы и механизмы взаимодействия с ОС - следовательно, и разные алгоритмы.
Алгоритма управления агрегатом вообще не бывает, надо учитывать контекст.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 13:56 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Алексей, в том то и дело, что часто алгоритм работы агрегата/установки/процесса не зависит от средств реализации (ПЛК/ПК/Homo Sapiens).

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

Ладно, зависят Д-схемы от реализации. КАК описать, что вот эта схема будет работать только для ПЛК или только для ПК или еще чего-нибудь??? Как описать среду в которой будут работать схемы???


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 14:46 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5109
Откуда: Москва
hothing писал(а):
На работе столкнулись с проблемой: часто необходимо управление агрегатом/установкой/процессом реализовать разными средствами. В результате, у нас просто огромное количество реализаций одного и того же алгоритма для разных "сред", с отличиями (зависит от программиста). Мне кажется - это тупик.


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

1. Изобразить алгоритм в виде дракон-схемы.

2. Согласовать этот алгоритм с разными руководителями (или сотрудниками) вашей фирмы.

3. Доработать алгоритм по результатам согласования.

4. Принять доработанный алгоритм в качестве стандарта вашей фирмы.

5. С помощью этого стандарта добиться единообразия технических решений на фирме.

=============================

Мне кажется, язык ДРАКОН будет удобным средством для решения вашей задачи (если я правильно Вас понял).

Язык ДРАКОН позволяет изобразить Ваш алгоритм на любом уровне абстрации:

— в общем в виде, без деталей (для доклада начальству);

— в виде точной спецификации;

— в виде компьютерной программы для конкретного устройства.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 14:49 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
hothing писал(а):
часто алгоритм работы агрегата/установки/процесса не зависит от средств реализации (ПЛК/ПК/Homo Sapiens).
В той части, о которую здесь споткнулись - зависит всегда. А именно в реализации рабочего цикла.
Либо его надо самому делать, либо использовать предоставляемый системой.
Поэтому логично выделять независимую часть и рассматривать только её (как подпроограмму).

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

Цитата:
В результате, у нас просто огромное количество реализаций одного и того же алгоритма для разных "сред", с отличиями (зависит от программиста). Мне кажется - это тупик.
Конечно, тупик.

Цитата:
КАК описать, что вот эта схема будет работать только для ПЛК или только для ПК или еще чего-нибудь??? Как описать среду в которой будут работать схемы???
Писать отдельными процедурами.
Тогда неважно, откуда процедура будет вызываться - из прерывания, из супервизора ПЛК или из собственной программы на ПК.

То есть необходимо чётко отделять системный уровень от прикладного.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 19:21 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Уважаемый Владимир, Вы правы.

Д-схемы хотелось бы использовать не только для программирования, но и для объяснения принципа работы людям, для создания документации.

Но все равно, у меня пазл не складывается!

Т.е. для одной и той же сущности, у меня должны быть разные схемы (одна для человека, вторая для ПЛК, третья для ПК и т.д...)? Хорошо, пусть так. Но как сохранять целостность? Если будут внесены изменения в базовую схему, то должны быть скорректированы остальные схемы. Ладно, внесли изменения. Как проверить, что внесенные изменения соответствуют базовой схеме? Все вручную??? Это мало чем отличается от того что есть.

Мое видение такое. Есть единая схема, которая не зависит от средств реализации. Из этой схемы я могу получать, как схемы с меньшей детализацией (для людей), так и генерировать код (или схемы?) для исполнителя.
Но тогда нужны правила уменьшения детализации и преобразования схем. Так?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Февраль, 2015 21:19 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
hothing писал(а):
Но все равно, у меня пазл не складывается!

Я тоже столкнулся с подобной проблемой.
Отголоски столкновения здесь.

Ильченко Эдуард писал(а):
Из моего опыта, детализировать "до крайнего предела" алгоритм дракон-схемами очень накладно и не нужно.


К сожалению, классические дракон-схемы не очень подходят для описания программ, использующихся на ПЛК. Приходится налагать на схемы дополнительные условия.

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

1.
После активации алгоритма он выполняется в каждом цикле работы ПЛК.
2.
В каждом цикле алгоритм начинает работу с ветки, имя которой обозначает текущее состояние алгоритма.
3.
Иконы Адрес переводят алгоритм в соответствующее состояние.
4.
Ветка «Обработка событий» не является состоянием алгоритма и выполняется в том же цикле, в котором произошёл переход на неё.
5.
После прохождения иконы Конец работа алгоритма прекращается.


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


Вложения:
А1 - 03.png
А1 - 03.png [ 58.8 КБ | Просмотров: 13441 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Февраль, 2015 11:14 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
hothing писал(а):
Мое видение такое. Есть единая схема, которая не зависит от средств реализации. Из этой схемы я могу получать, как схемы с меньшей детализацией (для людей), так и генерировать код (или схемы?) для исполнителя.

Для Вашего случая можно попробовать начать вот с такой схемы:
Вложение:
a1.png
a1.png [ 26.6 КБ | Просмотров: 13421 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Февраль, 2015 12:52 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Вложение:
a2.png
a2.png [ 37.62 КБ | Просмотров: 13416 ]


Все действия, расположенные на актуальных маршрутах, в этих схемах и внутри цикла верхней схемы выполняются в одном цикле или ПЛК или WHILE.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Февраль, 2015 14:09 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Эдуард, спасибо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2015 20:50 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
hothing писал(а):
Д-схемы хотелось бы использовать не только для программирования, но и для объяснения принципа работы людям, для создания документации.

Уважаемый hothing!

Удалось ли Вам победить д-схемы?
Если да и есть интересные результаты, не могли бы Вы поделиться добытыми знаниями?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2015 15:46 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 29
Откуда: Austria, Bruck
Здравствуйте, Эдуард.

К сожалению, приспособить Дракон для программ АСУ мне так и не удалось. Пока продолжаю попытки использовать Дракон, теперь как средство описания в документации. Хотя и в этом - проблемы, правда, технические. Схемы даже с максимальным использованием икон "вставка" часто не влезают на лист формата А4. Использование листов большего формата противоречит стандарту нашей фирмы. Вот такие "пироги".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2015 19:23 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
hothing писал(а):
Схемы даже с максимальным использованием икон "вставка" часто не влезают на лист формата А4.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Сентябрь, 2015 11:00 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
hothing писал(а):
Алексей, в том то и дело, что часто алгоритм работы агрегата/установки/процесса не зависит от средств реализации (ПЛК/ПК/Homo Sapiens).

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

Ильченко Эдуард писал(а):
hothing писал(а):
Но все равно, у меня пазл не складывается!

Я тоже столкнулся с подобной проблемой.
Отголоски столкновения здесь.

Аналогичный случай в нашей деревне (точнее оба случая).

Проблема в целом такая:
Параллельное, в общем случае, алгоритмическое обеспечение (подсистема алгоритмического обеспечения)
САПР автоматизированных технологических систем.
В предельно широкой интерпретации показателя автоматизации - от нуля и выше:
от ручных и механизированных рабочих мест и производственных подразделений (как объектов автоматизации)
до гибких (автоматизированных и роботизированных) производственных модулей и систем.
Это была реальная задача в конце перестройки, затем все это грохнулось (по понятным причинам),
сейчас теплится в учебном процессе и медленно снова реально надвигается.
Ждем-с. Бьем копытами.

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

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

------------------------------------
1) Простой пример - упрощенная запись токарной технологической операции:
Вложение:
ПредвПример-02.PNG
ПредвПример-02.PNG [ 99.39 КБ | Просмотров: 12761 ]

-------------------------------------
1.1) Реальные технологии задаются маршрутными и операционными картами - в табличной форме.
Раньше, это была вполне читабельная (без умственного напряга) списочная табличная форма:
-- перечень операций технологического процесса или переходов технологической операции (с разными данными);
-- он дополняется технологическими эскизами.
В связи с задачами внедрения САПР технологических процессов появилась новая система стандартов.
Первоначально документация была очень универсальная и реальные технологии получались слабо заполненные.
Затем их уплотнили и получились довольно мудреные форматы заполнения.
Я в свое время не успел разобраться, но надо будет.

Вопрос № 1 - может быть у кого-то будут ссылки на примеры.
Как увязать такую техдокументацию с графическими схемами алгоритмов:
проще говоря - куда вставлять Дракон-схемы и т.п.

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

Вопрос № 2 - может быть у кого-то будут ссылки на примеры.
Нужно или не нужно явно отображать эту информацию алгоритмами, например в Драконе и т.п.:
в учебной или рабочей документации.

1.2.1) В частности, в отношении сопутствующего технического контроля.
В терминах Эдуарда Ильченко традиционная технологическая документация - это "нормальные алгоритмы"
здесь:
Цитата:
выкристализировалось понятие «нормализованный алгоритм»
(более точно «нормализованное описание алгоритма»).
Т.е. такое описание алгоритма, при котором схема явным образом описывает только действия,
которые выполняются при нормальной работе оборудования и при нормальных технологических условиях.

Вот это очень кстати, спасибо автору такой клисталлизации.
У меня лично это давно зудило, но пока руки не доходили заняться этим.

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

Вопрос № 3 - может быть у кого-то будут соображения и ссылки на примеры:
- нужна ли дополнительная полная алгоритмическая информация с учетом наличия и последствий технического контроля, например в Дракон-схемах;
- как она сочетается с первичной нормальной технологией:
какая-то иерархия?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 17 Январь, 2016 20:30 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5109
Откуда: Москва
hothing писал(а):
К сожалению, приспособить Дракон для программ АСУ мне так и не удалось. Пока продолжаю попытки использовать Дракон, теперь как средство описания в документации. Хотя и в этом - проблемы, правда, технические. Схемы даже с максимальным использованием икон "вставка" часто не влезают на лист формата А4. Использование листов большего формата противоречит стандарту нашей фирмы. Вот такие "пироги".


Стандарт фирмы часто отстает от жизни. Проблемы становятся все более сложными. Стандарт фирмы, требующий формат А4, отстал от жизни. Формат А4 ограничивает возможности нашего мозга. Это необходимо учитывать.

Это отнюдь не мелочь (как думают многие), а очень серьезная трудность.

Это очень старая проблема. Я помню, как Джеймс Мартин, автор 100 с лишним замечательных книг, отстаивал необходимость испольования формата А4 и НЕ БОЛЬШЕ.
Устаревшая точка зрения, но она очень живучая.

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

Переход на формат А3 — уже большой шаг вперед.
Потому что на формате А3 можно смоделировать лист А1 (с уменьшением масштаба).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 17 Январь, 2016 21:05 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1156
В ИС Дракон нет проблемы.
====
Очень удобно пользоваться графическим редактором Paint. В нем присутствует необходимая функциональность.
Небольшие схемы можно вставлять из системного буфера в текстовом редакторе Word.
При выборе в ИС Дракон листа или схемы, соответственно сохраняется (копируется) весь лист или выбранная схема.
====
Как напечатать лист или схему?

Выполнить пункт "Файл / Открыть графический файл ..." или
в редакторе PAINT открыть сохраненный графический файл.
Можно использовать другой графический редактор.
Можно вставить изображение из системного буфера.
Можно в редакторе изображение дополнить своей информацией.

Выбрать ориентацию листов бумаги, установить размер полей = 0,
выбрать раскладку нескольких листов для размещения изображения, выбрать масштаб.

Напечатать, обрезать часть полей и склеить листы.

Можно использовать текстовый редактор и вставить изображение из системного буфера.
====
Напечатайте на домашнем или рабочем принтере.
Бумажную копию склеить из форматов А4, сложить (в Гостах есть указание как сложить) и приложить к документации. Склеить в лист хоть до формата А0.
Сложение чертежей ГОСТ 2.501-88 -
http://www.jetcom.ru/production/es-te/application/GOST-folding/ ,
http://docs.cntd.ru/document/gost-2-501-88-eskd .
====
В. Паронджанова предлагает применять так называемые иконы Соединитель. Предложение не имеет практического смысла.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Январь, 2016 14:07 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1156
Владимир Паронджанов писал(а):
Это организационная проблема. Ее можно и нужно решать.
Владимир Паронджанов, решение проблемы предложено, оно Вас удовлетворило?


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

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


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

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


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

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