А если нет — то людей, которые «это» сотворили нужно уволить и нанять других.
Экий вы шустрый. Всех уволить, набрать хороших. Очень напоминает высказывание наших чиновников, которые супер компетентные, супер эффективные и вообще профи. Просто с народом им не повезло. И надо всех уволить и набрать других.
Что очень и очень грустно.
Сколько патетики. Конечно хорошо, что люди переживают за будущее нашей страны. Но так трагично заламывать руки все же не стоит. Везде есть свои плюсы и минусы. Везде есть своя специфика работы. И не разбираясь серьезно в этом делать поспешные выводы неразумно т.к. высока вероятность ошибиться.
Но как тут уже говорилось: для того, чтобы реализовывать реально сложные алгоритмы требуются реально сложные же и языки программирования.
Ну так МЭК 61131 описывает пять языков. Выбирайте тот, что вам по вкусу.
И еще раз повторюсь — сложные алгоритмы и красивая их реализация на чем-нибудь хитровывернутом это хорошо. Вот только обратной стороной медали является полное закрытие технологической программы от эксплуатации из-за высокого порога вхождения. Что полностью убьет конкурентноспособность вашего изделия. Хотя никто не запрещает писать на том же ST.
Да уж.
Да не вопрос. Хотите менять алгоритмы и переделывать программы на объекте — пожалуйста. Только перед этим бумагу подпишите, что принимаете на себя все риски, связанные с ошибками в программе (причем не только в той части, которую будете править, т.к. сложно разделить единый технологически связанный объект на куски). И вперед. Вот только готова ли будет ваша компания пойти на это?
Задачи, жёстко завязанные на безопасность (какое-нибудь аварийное отключение атомного реатора) лучше всего делать вообще без всякого ПО (простейшая аппаратная схема)
Звучит как призыв: «Вперед в прошлое!». От релейных схем все уходят. Аппаратные защиты в ответственных узлах уже не используются. Все перенесено на микроконтроллеры. Причем эта тенденция наблюдается во всем мире.
Я чуть выше неточно выразился. Имеется ввиду популярные и распространенные языки. А то тут есть статья когда человек «Hello, World» писал примерно вот так:
Можно программу написать так, чтоб она была понятной, а можно и запутать так, что нихрена не разберешься даже с поллитрой.
А кто мне запретит-то? Откуда такие странные ограничения?
Специфика АСУ ТП. Работает объект, управляемый контроллером с такой вот программой. Там все приемосдаточные испытания проведены, протоколы подписаны и т.д. И никто не даст вам лезть и что то сильно менять. Только маленький кусочек или вообще несколько констант. Т.е. любое форматирование того что есть исключено.
А сделать это на FBD — это как «автогеном через жопу», я извиняюсь, гланды вырезать…
Конечно. Просто в вашем примере и в моем решаются принципиально разные задачи. И если в вашем примере это выглядит как вырезание гланд, то в моем — очень органично.
Помимо порога вхождения важен еще и верхний порог, характеризующий возможности инструмента
Согласен. Поэтому когда мы разрабатывали эту систему, то все время присутствовала обратная связь в лице специалистов по проектированию и эксплуатации. И вот этот верхний порог подгонялся под их нужды и в итоге всех устраивал.
Разумеется при грамотной организации исходных текстов.
Вот оно, то самое «если». Если текст будет нормально написан. Если везде будут комменты. Если будут использованы стандартные приемы. Если (при большом проекте) будет более или менее логичная и понятная архитектура. И т.д.
возникает ощущение, что мы вообще о задачах разных масштабов говорим…
Конечно. Я с самого начала сказал что в технологическом программировании в АСУ ТП есть своя специфика. Просто в посте я не написал подробнее т.к. писал в предыдущих статьях и не хотел повторяться.
Откуда там взялась «сотня разнотипных параметров»?
Нет никакой сотни разнотипных параметров. Обычно это температура, давление, расход, уровень, положение и остальные по мелочи. Исполнительных механизмов тоже несколько видов: двигатель, задвижка да несколько разных типов клапанов. Однако количество датчиков и исполнительных механизмов напрямую влияет на сложность программы. И программа с несколькими сотнями датчиков и сотней арматурин уже довольно сложная штука.
Как пример — посмотрите мой самый первый пост. Там (внезапно) 9000 блоков. И что? Разве такое количество вызывает какие-то непреодолимые проблемы? В той программе можно минут за 20 разобраться от и до.
С другой стороны бывает «мешанина» из какой нибудь полусотни блоков. И сделаны они так, что там сам черт ногу сломит, пытаясь разобраться что к чему.
Т.е. все зависит от качества написания программ. Хотел программист сделать их удобными и понятными для всех или лепил как получится. И от языка это не сильно зависит. Вот вам пример из С:
Ужасно, правда? И представьте что вам нужно в этом разобраться но при этом вы не можете форматировать текст, поставить отступы, пробелы, нет подсветки синтаксиса и т.п.
Почему то не могу отредактировать свой коммент.
В общем т.к. ничего от объектно ориентированного программирования в тексте нет, то как то совестно было говорить о плюсах :D
И показывает что у программистов — таки мозги реально в чём-то другие.
FBD пишется в основном для технологов. Но кстати и отладка проекта на объекте при непрерывных процессах на FBD гораздо проще чем на том же ST.
когда я вижу все эти «безумные схемы», то у меня по первости никаких словей, кроме матерных в голове не возникает
Это именно первое впечатление. Достаточно поковыряться минут 15-20 и все становится легко и понятно. Просто вы возможно привыкли к тому же С. Чувствуете там себя как рыба в воде. Разумеется первая реакция на совершенно другую непривычную вещь будет именно такой.
вы в нём разберётесь??? Это же жуть будет!
Это будет жуть, но в ней при правильном подходе будет несложно разобраться. И при хорошей структурированности программы думаю даже далекие от таких сложных алгоритмов люди, владеющие только азами логики и базовых алгоритмов, посидев и поковырявшись в программе поймут что к чему.
Когда рассматриваются примеры типа Hello World (а на FBD — элементарная логическая схема) то и там, и там все предельно просто. Когда же дело доходит до действительно сложных задач...
Тут есть два момента:
1. Действительно сложную задачу нужно стараться сделать так, чтобы она получилась, образно говоря, из кучи маленьких кусочков типа «Hello, World». У нас сотрудники делали алгоритмы автоматического розжига котла целиком на FBD. Там контроль сотен параметров и управление сотней арматуры. Задача реально большая и сложная. Однако при рассмотрении она разбирается на много маленьких простых кусочков с основой из элементарных функций типа логики, триггеров и таймеров.
2. Важен порог вхождения стороннего человека. Есть на объекте технолог и в какой то момент что то в технологии поменялось. Этот технолог — он не гуру в программировании. Более того, он вообще никак с программированием не связан. Однако нужно обеспечить ему возможность влезть в программу контроллера и подправить ее в соответствии с изменившейся технологией. И сделать это нужно оперативно. Как вы считаете, что будет проще: ковыряться в текстовых исходниках, правя константы, ветки if и т.п. или найти несколько блоков проверки условий и задать на них новые значения?
Да. Вы правы. Упустил этот момент из вида. (а я думал что эти квадратики и описание к ним вообще никто не смотрит :) )
В принципе эта функция реализуется легко. Если с минимальными переделками, то нужно на каждую клетку заводить не только ближайших соседей, но и весь ряд вообще. И при клике на клетку просматривать весь ряд и каскадом сдвигать по очереди все (в пределе 3) плитки.
Т.к. функция уже займет не 2 цикла как сейчас, а шесть, придется еще наружу блокировку вывести, чтобы подстраховаться от наложения команд.
А вот в это, извините — но не верю. Особенно в свете вот этого:
Почему же? «Реализовать на FBD алгоритм» и «изучить технологию для дальнейшего написания алгоритмов» это совсем разные вещи. Второе нереально, а вот первое — без проблем.
Если вы этим занимаетесь, то, может быть, у вас есть статистика?
По моему личному опыту (возможно если сюда заглянут люди, непосредственно занимающиеся внедрением АСУ ТП в различных областях и на разных системах то они поправят/дополнят) процентов 80 всех программ АСУ ТП в области энергетики пишется на FBD. Еще 15% на ST. Остальные 5% на оставшиеся 3 языка.
И FBD популярен именно потому, что даже если кто-то другой наворотил в контроллере черт знает что, то разобраться что и как там работает при использовании FBD гораздо проще и быстрее, чем на каком-либо другом языке.
По-моему мы с вами говорим о разных вещах совершенно. FBD это один из пяти языков программирования МЭК 61131.
Эти языки используются для так называемого «технологического» программирования микроконтроллеров.
Для каждой задачи один язык подходит больше, другой меньше. И конкретно в программировании в АСУ ТП я считаю, что FBD проще и нагляднее и удобнее всего остального. Это просто я делаю всякую ерунду типа игрушек т.к. узкоспециализированные алгоритмы управления техпроцессами вообще никому кроме пары десятков человек не интересны и непонятны.
Что касается понимания как работает счетчик или триггер или что значит сложение двух сигналов по И. Могу поспорить, что это за 15 минут можно объяснить это любому школьнику, после чего он из таких блоков сможет писать полноценные технологические программы. А вот основам того же языка С (или ST как что то похожее из МЭК 61131) за 15 минут вы никого не научите.
Да, про swap(a,b); не знал. Теперь буду знать. И на самом деле таких вот тонкостей полно.
Что касается функций — опять таки вопрос синтаксиса. Чтобы ее прописать, нужно знать как ее объявить, что ей передать, что она возвращает и как ее вызвать. А на FBD это точно такой же блок как и операция ИЛИ. Поставил на поле, привязал «веревки» и все работает.
«Забавно. А фраза «язык FBD это простой и понятный язык» — это сарказм или нет?»
В каждой фразе есть доля сарказма. Но тут его немного.
Я в следующем посте, когда сойдутся звезды, желание и свободное время, попробую сделать одну и ту же программу на FBD и ST. И можно будет сравнить, что проще. Хотя подозреваю, что любое мнение тут будет субъективным.
Возможно. Каждому свое.
Но уточним пару моментов:
1. В данном примере явно не «пара ватманов со связями». Вся программа умещается на А3.
2. Программа на «пару ватманов со связями» в текстовом виде будет явно не один лист. И даже не два. И не три.
3. Еще хотелось бы обратить внимание, но в данном примере на FBD вся программа это фактически повторение один в один 16 раз связки из одного макроса и семи простейших (сравнение, память, ИЛИ) блоков плюс еще полтора десятка простейших блоков обвязки.
Поэтому ваш вопрос касается явно утрированной ситуации.
Главное преимущество FBD — возможность по связям быстро проследить логику работы программы. Вот в подобной вещи я например разберусь без комментариев за пятнадцать минут. С комментариями минут за пять.
Ну и кроме того (в этом посте я в отличие от предыдущих не акцентировал на этом внимание), написать программу на FBD может любой человек, знакомый с основами логики (операции И, ИЛИ, НЕ) и примерно представляющий как работает счетчик и триггер. А чтобы написать подобную же программу на том же С нужно потратить кучу времени на гугленье основ синтаксиса, возможностей языка, реализаций тех или иных конструкций и т.д. и т.п. Т.е. решить эту задачу с ходу не получится.
Экий вы шустрый. Всех уволить, набрать хороших. Очень напоминает высказывание наших чиновников, которые супер компетентные, супер эффективные и вообще профи. Просто с народом им не повезло. И надо всех уволить и набрать других.
Сколько патетики. Конечно хорошо, что люди переживают за будущее нашей страны. Но так трагично заламывать руки все же не стоит. Везде есть свои плюсы и минусы. Везде есть своя специфика работы. И не разбираясь серьезно в этом делать поспешные выводы неразумно т.к. высока вероятность ошибиться.
Ну так МЭК 61131 описывает пять языков. Выбирайте тот, что вам по вкусу.
И еще раз повторюсь — сложные алгоритмы и красивая их реализация на чем-нибудь хитровывернутом это хорошо. Вот только обратной стороной медали является полное закрытие технологической программы от эксплуатации из-за высокого порога вхождения. Что полностью убьет конкурентноспособность вашего изделия. Хотя никто не запрещает писать на том же ST.
Да не вопрос. Хотите менять алгоритмы и переделывать программы на объекте — пожалуйста. Только перед этим бумагу подпишите, что принимаете на себя все риски, связанные с ошибками в программе (причем не только в той части, которую будете править, т.к. сложно разделить единый технологически связанный объект на куски). И вперед. Вот только готова ли будет ваша компания пойти на это?
Звучит как призыв: «Вперед в прошлое!». От релейных схем все уходят. Аппаратные защиты в ответственных узлах уже не используются. Все перенесено на микроконтроллеры. Причем эта тенденция наблюдается во всем мире.
Я чуть выше неточно выразился. Имеется ввиду популярные и распространенные языки. А то тут есть статья когда человек «Hello, World» писал примерно вот так:
Можно программу написать так, чтоб она была понятной, а можно и запутать так, что нихрена не разберешься даже с поллитрой.
Специфика АСУ ТП. Работает объект, управляемый контроллером с такой вот программой. Там все приемосдаточные испытания проведены, протоколы подписаны и т.д. И никто не даст вам лезть и что то сильно менять. Только маленький кусочек или вообще несколько констант. Т.е. любое форматирование того что есть исключено.
Конечно. Просто в вашем примере и в моем решаются принципиально разные задачи. И если в вашем примере это выглядит как вырезание гланд, то в моем — очень органично.
Согласен. Поэтому когда мы разрабатывали эту систему, то все время присутствовала обратная связь в лице специалистов по проектированию и эксплуатации. И вот этот верхний порог подгонялся под их нужды и в итоге всех устраивал.
Вот оно, то самое «если». Если текст будет нормально написан. Если везде будут комменты. Если будут использованы стандартные приемы. Если (при большом проекте) будет более или менее логичная и понятная архитектура. И т.д.
А если нет?
Конечно. Я с самого начала сказал что в технологическом программировании в АСУ ТП есть своя специфика. Просто в посте я не написал подробнее т.к. писал в предыдущих статьях и не хотел повторяться.
Нет никакой сотни разнотипных параметров. Обычно это температура, давление, расход, уровень, положение и остальные по мелочи. Исполнительных механизмов тоже несколько видов: двигатель, задвижка да несколько разных типов клапанов. Однако количество датчиков и исполнительных механизмов напрямую влияет на сложность программы. И программа с несколькими сотнями датчиков и сотней арматурин уже довольно сложная штука.
С другой стороны бывает «мешанина» из какой нибудь полусотни блоков. И сделаны они так, что там сам черт ногу сломит, пытаясь разобраться что к чему.
Т.е. все зависит от качества написания программ. Хотел программист сделать их удобными и понятными для всех или лепил как получится. И от языка это не сильно зависит. Вот вам пример из С:
Ужасно, правда? И представьте что вам нужно в этом разобраться но при этом вы не можете форматировать текст, поставить отступы, пробелы, нет подсветки синтаксиса и т.п.
В общем т.к. ничего от объектно ориентированного программирования в тексте нет, то как то совестно было говорить о плюсах :D
FBD пишется в основном для технологов. Но кстати и отладка проекта на объекте при непрерывных процессах на FBD гораздо проще чем на том же ST.
Это именно первое впечатление. Достаточно поковыряться минут 15-20 и все становится легко и понятно. Просто вы возможно привыкли к тому же С. Чувствуете там себя как рыба в воде. Разумеется первая реакция на совершенно другую непривычную вещь будет именно такой.
Это будет жуть, но в ней при правильном подходе будет несложно разобраться. И при хорошей структурированности программы думаю даже далекие от таких сложных алгоритмов люди, владеющие только азами логики и базовых алгоритмов, посидев и поковырявшись в программе поймут что к чему.
Тут есть два момента:
1. Действительно сложную задачу нужно стараться сделать так, чтобы она получилась, образно говоря, из кучи маленьких кусочков типа «Hello, World». У нас сотрудники делали алгоритмы автоматического розжига котла целиком на FBD. Там контроль сотен параметров и управление сотней арматуры. Задача реально большая и сложная. Однако при рассмотрении она разбирается на много маленьких простых кусочков с основой из элементарных функций типа логики, триггеров и таймеров.
2. Важен порог вхождения стороннего человека. Есть на объекте технолог и в какой то момент что то в технологии поменялось. Этот технолог — он не гуру в программировании. Более того, он вообще никак с программированием не связан. Однако нужно обеспечить ему возможность влезть в программу контроллера и подправить ее в соответствии с изменившейся технологией. И сделать это нужно оперативно. Как вы считаете, что будет проще: ковыряться в текстовых исходниках, правя константы, ветки if и т.п. или найти несколько блоков проверки условий и задать на них новые значения?
В принципе эта функция реализуется легко. Если с минимальными переделками, то нужно на каждую клетку заводить не только ближайших соседей, но и весь ряд вообще. И при клике на клетку просматривать весь ряд и каскадом сдвигать по очереди все (в пределе 3) плитки.
Т.к. функция уже займет не 2 цикла как сейчас, а шесть, придется еще наружу блокировку вывести, чтобы подстраховаться от наложения команд.
В целом же алгоритм не изменится.
Почему же? «Реализовать на FBD алгоритм» и «изучить технологию для дальнейшего написания алгоритмов» это совсем разные вещи. Второе нереально, а вот первое — без проблем.
По моему личному опыту (возможно если сюда заглянут люди, непосредственно занимающиеся внедрением АСУ ТП в различных областях и на разных системах то они поправят/дополнят) процентов 80 всех программ АСУ ТП в области энергетики пишется на FBD. Еще 15% на ST. Остальные 5% на оставшиеся 3 языка.
И FBD популярен именно потому, что даже если кто-то другой наворотил в контроллере черт знает что, то разобраться что и как там работает при использовании FBD гораздо проще и быстрее, чем на каком-либо другом языке.
Эти языки используются для так называемого «технологического» программирования микроконтроллеров.
Для каждой задачи один язык подходит больше, другой меньше. И конкретно в программировании в АСУ ТП я считаю, что FBD проще и нагляднее и удобнее всего остального. Это просто я делаю всякую ерунду типа игрушек т.к. узкоспециализированные алгоритмы управления техпроцессами вообще никому кроме пары десятков человек не интересны и непонятны.
Что касается понимания как работает счетчик или триггер или что значит сложение двух сигналов по И. Могу поспорить, что это за 15 минут можно объяснить это любому школьнику, после чего он из таких блоков сможет писать полноценные технологические программы. А вот основам того же языка С (или ST как что то похожее из МЭК 61131) за 15 минут вы никого не научите.
Что касается функций — опять таки вопрос синтаксиса. Чтобы ее прописать, нужно знать как ее объявить, что ей передать, что она возвращает и как ее вызвать. А на FBD это точно такой же блок как и операция ИЛИ. Поставил на поле, привязал «веревки» и все работает.
В каждой фразе есть доля сарказма. Но тут его немного.
Я в следующем посте, когда сойдутся звезды, желание и свободное время, попробую сделать одну и ту же программу на FBD и ST. И можно будет сравнить, что проще. Хотя подозреваю, что любое мнение тут будет субъективным.
Но уточним пару моментов:
1. В данном примере явно не «пара ватманов со связями». Вся программа умещается на А3.
2. Программа на «пару ватманов со связями» в текстовом виде будет явно не один лист. И даже не два. И не три.
3. Еще хотелось бы обратить внимание, но в данном примере на FBD вся программа это фактически повторение один в один 16 раз связки из одного макроса и семи простейших (сравнение, память, ИЛИ) блоков плюс еще полтора десятка простейших блоков обвязки.
Поэтому ваш вопрос касается явно утрированной ситуации.
Главное преимущество FBD — возможность по связям быстро проследить логику работы программы. Вот в подобной вещи я например разберусь без комментариев за пятнадцать минут. С комментариями минут за пять.
Ну и кроме того (в этом посте я в отличие от предыдущих не акцентировал на этом внимание), написать программу на FBD может любой человек, знакомый с основами логики (операции И, ИЛИ, НЕ) и примерно представляющий как работает счетчик и триггер. А чтобы написать подобную же программу на том же С нужно потратить кучу времени на гугленье основ синтаксиса, возможностей языка, реализаций тех или иных конструкций и т.д. и т.п. Т.е. решить эту задачу с ходу не получится.