Почитать наверное на официальном сайте: www.niiteplopribor.ru
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
Это и не FBD. Там есть поддержка типов данных, в том числе структур. Так же данные делятся на потенциальные (мгновенное значение) и команды (буферизуемые значения). Так же имеется встроенная поддержка качества значений. Можно проводить обратные связи, они выделяются зеброй. При этом в качестве начальных значений берутся значения типа данных по умолчанию (прописывается в самом типе).
В общем там вагон всего, еще я планировал впилить туда контроль порядка выполнения в виде связей и поддержку условий. Тогда был бы полный Франкенштейн из FBD, SFC и обычных блок-схем.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
А с чем вы не согласны?
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
Все предельно просто.
Т.к. я сначала написал прогу, а потом уже писал текст и вырезал картинки, то картинку с генератором я вырезал из программы со связями. А когда писал текст, то по ходу рассказа он должен был идти отдельно. Мне было очень лень запускать пилон, ставить отдельно макрос и делать новую картинку, поэтому я просто в паинтбраше стер входящие на алгоблок связи и дописал значения по умолчанию веселым голубым цветом. Если присмотреться, то там даже его номер (восьмой) остался как в главной программе.
Даже то, что реализовано на данный момент, полностью покрывает все задачи в АСУ ТП. Ну а чего в стандартных схемах нет, можно добавить в виде своих плюшек макросами.
Хотя слова «поддержка условий» звучат заманчиво.
PS. Спорим, что я с трех попыток угадаю кто написал комментарий выше? А скорее всего даже с одной.
UPD: Оказывается, вы правоприемники Ремиконта! Приятный сюрприз — изучал их в университете, наши преподаватели в его навесном шкафу коньяк прятали =)
Небось коньяк «Квинт».
Если честно, то на придумывание схемы хвоста ушло конечно же больше времени (где то в обед мне прислали ссылку на ваш пост и взяли на «слабо», и в течение вечера пока было свободное время я прикидывал как это можно сделать попроще). Уж очень не хотелось ставить 400 триггеров. Но перебирая в уме различные варианты все равно упирался в то, что без кучи запоминающих элементов не обойтись (была перспективная идея хранить не целиком хвост змеи в памяти, а только координаты точек перегиба, но в пределе длина змеи может составлять 400 клеток и точек перегиба может быть столько же, а т.к. динамической памяти в программе нет, то этот вариант отпал).
Ну а когда решение было принято, то набросать программу было уже делом техники, ведь все блоки сделаны предельно примитивно, а поддержка макросов позволяет за пару минут сделать 400 ячеек памяти. Так что фактически я написал один элемент и свернул в макрос «Ячейка_памяти». Затем сделал макрос «Упаковка» в который поместил 20 макросов «Ячейка_памяти», а затем поставил в задачу 20 макросов «Упаковка» и все готово.
В двух словах не расскажешь.
Хотел кинуть ссылку на брошюру с сайта НИИТеплоприбора, но потом увидел какая она ужасная в плане оформления.
Но если интересно, более подробную информацию можно найти тут.
Какая тонкая ирония.
Соглашусь с вами, действительно получился перебор.
Но это только потому, что реально обидно, когда все знают «буржуйские» системы и превозносят их до небес, в то время как отечественные разработки порой превосходят иностранные аналоги, но о них знает лишь очень и очень узкий круг специалистов.
Т.к. модули маленькие, то места для светодиодов не нашлось. Да и сами модули имеют всего лишь 16 дискретных выходов.
Так что без паяльника и отвертки тут не обойтись. Но это уже не столь интересно, т.к. все уже готово, нужно только припаять и прикрутить 808 проводков.
На самом деле это сделать гораздо проще, чем написать программу.
Единственная загвоздка тут в 400 диодов и кто будет их распаивать и привинчивать проводки к модулям ЦДП.
Но вы же понимаете, что без АРМа управлять змейкой все равно не получится. Так что чисто на контроллер перейти не удастся.
Хотя с другой стороны у контроллера есть 4 кнопки, которые в теории можно привязать к командам.
Или кстати можно 4 кнопки завести на модули ДЦП и с них подавать команды. Тогда остается проблема только с распайкой.
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
Т.к. я сначала написал прогу, а потом уже писал текст и вырезал картинки, то картинку с генератором я вырезал из программы со связями. А когда писал текст, то по ходу рассказа он должен был идти отдельно. Мне было очень лень запускать пилон, ставить отдельно макрос и делать новую картинку, поэтому я просто в паинтбраше стер входящие на алгоблок связи и дописал значения по умолчанию веселым голубым цветом. Если присмотреться, то там даже его номер (восьмой) остался как в главной программе.
Хотя слова «поддержка условий» звучат заманчиво.
PS. Спорим, что я с трех попыток угадаю кто написал комментарий выше? А скорее всего даже с одной.
Если честно, то на придумывание схемы хвоста ушло конечно же больше времени (где то в обед мне прислали ссылку на ваш пост и взяли на «слабо», и в течение вечера пока было свободное время я прикидывал как это можно сделать попроще). Уж очень не хотелось ставить 400 триггеров. Но перебирая в уме различные варианты все равно упирался в то, что без кучи запоминающих элементов не обойтись (была перспективная идея хранить не целиком хвост змеи в памяти, а только координаты точек перегиба, но в пределе длина змеи может составлять 400 клеток и точек перегиба может быть столько же, а т.к. динамической памяти в программе нет, то этот вариант отпал).
Ну а когда решение было принято, то набросать программу было уже делом техники, ведь все блоки сделаны предельно примитивно, а поддержка макросов позволяет за пару минут сделать 400 ячеек памяти. Так что фактически я написал один элемент и свернул в макрос «Ячейка_памяти». Затем сделал макрос «Упаковка» в который поместил 20 макросов «Ячейка_памяти», а затем поставил в задачу 20 макросов «Упаковка» и все готово.
Хотел кинуть ссылку на брошюру с сайта НИИТеплоприбора, но потом увидел какая она ужасная в плане оформления.
Но если интересно, более подробную информацию можно найти тут.
Соглашусь с вами, действительно получился перебор.
Но это только потому, что реально обидно, когда все знают «буржуйские» системы и превозносят их до небес, в то время как отечественные разработки порой превосходят иностранные аналоги, но о них знает лишь очень и очень узкий круг специалистов.
Так что без паяльника и отвертки тут не обойтись. Но это уже не столь интересно, т.к. все уже готово, нужно только припаять и прикрутить 808 проводков.
Единственная загвоздка тут в 400 диодов и кто будет их распаивать и привинчивать проводки к модулям ЦДП.
Но вы же понимаете, что без АРМа управлять змейкой все равно не получится. Так что чисто на контроллер перейти не удастся.
Хотя с другой стороны у контроллера есть 4 кнопки, которые в теории можно привязать к командам.
Или кстати можно 4 кнопки завести на модули ДЦП и с них подавать команды. Тогда остается проблема только с распайкой.