Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Алгоритм циклической загрузки-разгрузки аппарата (страница 1)

Версия для печати (настроить)
Страницы: 1 2

Новая тема | Написать ответ

Подписаться

Автор Тема:   Алгоритм циклической загрузки-разгрузки аппарата
Avsha
Member

Сообщений: 71
Регистрация: Июль 2005

написано 28 Декабря 2005 10:00ИнфоПравкаОтветитьIP

Всем добрый день,
Требуется реализовать алгоритм циклической загрузки-разгрузки аппарата,
на каком языке это лучше реализовывать в Isagraf?
Язык последовательных функциональных схем (SFC)
Язык потоковых диаграмм (FС)
Язык функциональных блочных диаграмм (FBD)
Язык релейных диаграмм (LD)
Язык структурированный текст (ST)
Язык инструкций (IL)
Алгоритм упрощенно выглядит так:
---------------------------------------------------------------
1. Открываем кран загрузки
2. При верхнем уровне в аппарате - Закрываем кран загрузки
3. Открываем кран разгрузки
4. При нижнем уровне в аппарате - Закрываем кран разгрузки
и т.д. опять по кругу
---------------------------------------------------------------

CHANt
Junior Member

Сообщений: 8
Откуда: Orenburg
Регистрация: Май 2004

написано 28 Декабря 2005 10:29ИнфоПравкаОтветитьIP

На мой взгляд, на время отладки в любом графическом, всегда "посоветоваться" с технологами можно.
После откладки - в IL или ST - меньше памяти займет.
Подразумеваю, что делать будете для себя. Иначе, что заказчик в требованиях выставил.

Dmitry M. Gaidash
Junior Member

Сообщений: 24
Регистрация: Сентябрь 2005

написано 28 Декабря 2005 10:51ИнфоПравкаОтветитьIP

В любом, ИМХО. Это не тот случай, когда надо языки выбирать.

Avsha
Member

Сообщений: 72
Регистрация: Июль 2005

написано 28 Декабря 2005 12:00ИнфоПравкаОтветитьIP

У нас традиционно сложилось программирование на FBD с использованием функциональных блоков, написанных на ST.
Это алгоритмы аналоговых/импульсных регуляторов, дискретное управлнение клапанами, насосами.

Мне почему-то казалось что алгоритмы такого типа (циклического режима)лучше реализовывать в SFC, но опыта работы с ним нет.
Приоритетом ставим надежность, возможность отладки/контроля выполнения алгоритма, приспособленность языка под данную задачу.

Dmitry M. Gaidash
По каким критериям и когда, по вашему необходимо выбирать тип языка?

Anatol_K
unregistered
написано 28 Декабря 2005 12:43  ПравкаОтветитьIP

Я думаю так, что это не алгоритм циклический - а физических процесс происходит циклически. Например - температура ниже нижней уставки - включакм нагреватеь, выше верхней уставки - отключаем нагреватель. И таких вещей в производстве -навалом. Логика объясняется на пальцах, вот и делать ее надо на простейшей логике с ипользованием элементов, широко представленных в FBD, а на SFC такие вещи делать не стоит. Это язык логических автоматов, в котором запоминаются внутренние состояния. Стоит ли рисовать граф переходов, если такой алгоритм можно реализовать на десятке блоков И,ИЛИ,НЕ?

Dmitry M. Gaidash
Junior Member

Сообщений: 25
Регистрация: Сентябрь 2005

написано 28 Декабря 2005 12:46ИнфоПравкаОтветитьIP

Avsha
когда, по вашему необходимо выбирать тип языка?
Когда критично быстродействие и при достаточно сложном алгоритме (разветвленном, нелинейном и т.д.), например. Или когда требуется сопровождение и тиражирование кода.

У нас традиционно сложилось
Ну вот как сложилось, так и пишите

Avsha
Member

Сообщений: 73
Регистрация: Июль 2005

написано 28 Декабря 2005 13:43ИнфоПравкаОтветитьIP

Anatol_K
Вот я и забочусь об этих внутренних состояниях.
Переход от одного состояния аппарата к другому происходит по фронту дискретного сигнала условия (верхний уровень например), а затем этот сигнал условия снимается, а состояние аппарата продолжает оставаться неизменным до появления нового условия.

В данном случае возникновение двух команд одновременно на загрузку и разгрузку недопустимо,
но теоретически возможно при возникновении двух одновременных условий.
А язык SFC вроде это как-то разруливает, отслеживая и регулируя порядок изменения состояний объекта и выдачу команд управления.

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

Dmitry M. Gaidash
Или когда требуется сопровождение и тиражирование кода.
Тоже такая проблема стоит, точь в точь как вы написали.

bessonov
Member

Сообщений: 126
Откуда: Россия
Регистрация: Август 2003

написано 28 Декабря 2005 13:50ИнфоПравкаОтветитьIP

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

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

Anatol_K
unregistered
написано 28 Декабря 2005 14:05  ПравкаОтветитьIP

Если вам важны внутренние состояния и четкая последовательность действий, то без триггрерных систем вы не обойдетесь. Если у вас сложилась практика создания блоко на ST, то сделайте набор стандартных блоков типа - блок полного графа трех состояний, четырех и т.д. Вам останется описать только термы переходов, что вы сможете сделать на FBD логике. Задачу можно упростить создавая блоки упрощенных графов, например циклический, тогда вы сможете выкинуть ненужные термы и не включать их в блок. Ну а если вам захочется повозиться на SFC - то это тоже очень удобный инструмент, только въезжать в него надо. Ну а киповцы маловероятно, что поймут что нибудь в вашем алгоритме без нормально документированного и описанного графа.
Ксати от ложных срабатываний может и граф состояний не спасти. Возможно на такие ложные сигналы следует вводить таймерные задержки.

Dmitry M. Gaidash
Junior Member

Сообщений: 26
Регистрация: Сентябрь 2005

написано 28 Декабря 2005 14:06ИнфоПравкаОтветитьIP

Avsha
А язык SFC вроде это как-то разруливает
Обычно это разруливает триггер с приоритетом по входу R или S.

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

bessonov

CHANt
Junior Member

Сообщений: 9
Откуда: Orenburg
Регистрация: Май 2004

написано 28 Декабря 2005 14:50ИнфоПравкаОтветитьIP

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

bessonov
Member

Сообщений: 127
Откуда: Россия
Регистрация: Август 2003

написано 28 Декабря 2005 14:57ИнфоПравкаОтветитьIP

Anatol_K
Возможно на такие ложные сигналы следует вводить таймерные задержки.

Конечно

Все эти проблемы появились не вчера. Триггеры, временные задержки это всё решалось схемотехнически, когда были простые логические микросхемы И, ИЛИ, НЕ.

В isagraf смотрите библиотеку стандартных функциональных блоков: TON, TOF, TP, F_TRIG, R_TRIG.

Anatol_K
unregistered
написано 28 Декабря 2005 15:37  ПравкаОтветитьIP

Пример автомата на три состояния с выходом из неопределлености, написанный на ST
Кому интересно, могу прокомментировать
begin
// S0-S1 - состояния
// Tmn - Термы переходов
// BLK - блокировка автомата со сбросом всех состояний

S0 := not (S1 or S2 or S3);

S1_set := (S0 and T01) or (S2 and T21) or (S3 and T31) ;
S2_set := (S0 and T02) or (S1 and T12) or (S3 and T32) ;
S3_set := (S0 and T03) or (S1 and T13) or (S2 and T23) ;

S1_tr := (S1_set or ( S1_tr and not S2_tr and not S3_tr)) and not BLK;
S2_tr := (S2_set or (not S1_tr and S2_tr and not S3_tr)) and not BLK;
S3_tr := (S3_set or (not S1_tr and not S2_tr and S3_tr)) and not BLK;

S1 := S1_tr and not S2_tr and not S3_tr ;
S2 := S2_tr and not S3_tr ;
S3 := S3_tr ;
end;

Павел Мощицкий
Member

Сообщений: 1231
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 28 Декабря 2005 23:56ИнфоПравкаОтветитьIP

Может кто-то попробует показать пример на LD? Хотя я в этом и не спец, но, по моему мнению, лучше оптимизировать удастся.

Avsha
Member

Сообщений: 74
Регистрация: Июль 2005

написано 29 Декабря 2005 07:19ИнфоПравкаОтветитьIP

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

Anatol_K
Потребуется ли обязательно составлять граф, при реализации на SFC не достаточно ли просто выделить состояния (загрузка/загружен/разгрузка/разгружен) и указать условия переходов из одного состояния в другой?

И еще вопрос, работают у кого-нибудь алгоритмы на SFC, и если да, то какого рода задачи они решают?

Anatol_K
unregistered
написано 29 Декабря 2005 13:35  ПравкаОтветитьIP

Конечно, я может чего то не понял, но судя по вашему описанию ваш граф имеет всего два состояния "Налив" и "Отлив". Зачем тут городить огород. При достижении верхнего уровня устанавливается "Отлив" - закрываете кран загрузки и открываете кран разгрузки. Это состояние продержится до достижения нижнего уровня. Теперь устанавливается состяние "Налив" - на краны подаются противоположные сигналы и продержится оно до достижения верхнего уровня. Есть тонкость. При первой инициализации алгоритма, при условии, что не сработал ни один уровень, следует предусмотреть выход из этой неопределлености путем добавления соответсвующих термов, вплоть до принудительной установки нужного состояния с АРМ оператора. Описанный автомат с двумя состояними легко реализуется на ST.
Может быть так, как ниже ? Я думаю здесь все прозрачно.
begin
// S1 Налив ; S2 - отлив
// LSL - нижний уровень ; LSH - верхний уровень
if (LSL and LSH) then
S1 := false ; S2 := false ; // выдаем аварийное сообщение, идем ремонтируем LSL и LSH,
S1_tr := false ; S2_tr := false ; // можете позакрывать еще и все краны, автомат сброшен
else
S0 := not (S1 or S2);
S1_set := (S0 and LSL) or (S2 and LSL);
S2_set := (S0 and LSH) or (S1 and LSH);
S1_tr := (S1_set or ( S1_tr and not S2_tr));
S2_tr := (S2_set or (not S1_tr and S2_tr));
S1 := S1_tr and not S2_tr; // выдать команды под загрузку
S2 := S2_tr; // выдать команды под разгрузку
end_if;
end;

Avsha
Member

Сообщений: 75
Регистрация: Июль 2005

написано 30 Декабря 2005 04:56ИнфоПравкаОтветитьIP

Anatol_K
Я немного упростил алгоритм в описании, в действительности условия открытия/закрытия загрузки и разгрузки несколько сложнее, поэтому я выделяю 4 состояния.
Спасибо за вариант на ST,
но мы как раз в этом случае не хотим все прятать в один блок, так как контроль за программой на ST - неудобен, а нам потребуется доработка алгоритма при испытаниях, и к тому же чтобы алгоритм читался ни одним специалистом.
В блоки на ST мы прячем простые, полностью законченные функции.
Начал пробовать SFC, вроде ничего получается.

KPY
Member

Сообщений: 304
Откуда: KZ
Регистрация: Май 2003

написано 03 Января 2006 10:01ИнфоПравкаОтветитьIP

Андрей, есть возможность использовать LD?
Очень удобно и наглядно получается. Релейная логика, ИМХО для твоего случая самое то. Завтра будет время накалякаю программку, сложнее придумать как фотку прикрепить к форуму. Могу в таком виде, но так читабельность ужасная.
BST XIC LSL NXB XIO LSH XIO LSL BND OTL S1 OTU S2

Avsha
Member

Сообщений: 76
Регистрация: Июль 2005

написано 03 Января 2006 10:09ИнфоПравкаОтветитьIP

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

Павел Мощицкий
Member

Сообщений: 1240
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 03 Января 2006 14:31ИнфоПравкаОтветитьIP

KPY
есть возможность использовать LD?
Будешь вторым, может после тебя услышат и попробуют применить.

Avsha
есть смысл его использовать
Его применение даст уменьшить сам код и приведет к оптимизации и более быстрому выполнению. Я привык к контроллерам относится с позиции уменьшения емкости кода и увеличению быстродействия. А SFC громоздок, требует вложенности дополнительных языков и увеличивает код. Лично я бы его применял при нужности параллельного выполнения нескольких задач (процессов). Это его преимущество.

Avsha_offline
unregistered
написано 04 Января 2006 02:35  ПравкаОтветитьIP

Я языком LD у меня давное знакомство , мне пришлось только его использовать для дипломной работы при программировании PLC GE Fanuc с помощью DOS-овской программы LogicMaster, других языков тогда просто не было.

Задача оптимизации кода у нас не стоит, вычислительная мощность контроллера нас не ограничивает, поэтому с этой позиции нам LD не интересен.
SFC интересен тем, что он пожалуй единственный из языков, который наглядно представляет последовательность изменения состояний объекта и условия перехода из одного состояния в другое. При знакомстве по примерам программ "Sample" в Isagraf мне он показался удобным (вообще не рекламируя Isagraf, просто идеальная среда для освоения языков всеми интересующимися с возможностью симуляции)

По алгоритму - мы остановились на FBD, но при наличии времени и желания попробуем реализовать на SFC и LD.

ColdFire
Member

Сообщений: 114
Откуда: Россия
Регистрация: Ноябрь 2004

написано 10 Января 2006 11:35ИнфоПравкаОтветитьIP

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

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

Совсем уж хорошо для этой задачи подошел бы State Logic от GE Fanuc - только судя по всему он в предсметрной агонии находится, да и требует отдельной аппартной платформы.

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

Добавление от 10 Января 2006 11:37:

цитата:
Avsha_offline писал:
Я языком LD у меня давное знакомство , мне пришлось только его использовать для дипломной работы при программировании PLC GE Fanuc с помощью DOS-овской программы LogicMaster, других языков тогда просто не было.

Неправда ваша - до LD, а позднее и параллельно с ним у фануков был чудесный язык IL Я недеюсь вы не программист на форте чтобы быть фанатом такого изврата ?

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

Добавление от 10 Января 2006 11:42:

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

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

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика