Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Вагон — это пять!
По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете.
А с чем вы не согласны?
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
Да уж, действительно, легко и весело :) Примерно, как сложить слово «вечность» из приведённых кубиков :))
Основная проблема — совсем уж бедность такого языка. Высокоуровневый язык с богатыми библиотеками даёт богатые возможности, но требует длительной подготовки. Бедный язык (такой, как FBD) даёт богатые возможности заново переизобрести колесо, велосипед и многое другое :))) И потрахаться на ровном месте с проблемой, о существовании которой даже не догадался бы, работая со старым добрым трубо паскалем или С++.
Короче, золотая середина между богатыми и бедными языками таки есть.
Кажущаяся простота таких языков несколько обманчива — как раз, таки, в силу простоты и минимализма. Разработчику не требуется серьёзной подготовки в плане самого языка, но без алгоритмической подготовки лучше даже не браться.
Скажем так: LAD (ладдер, релейно-контактная логика) и FBD (функциональные диаграммы) — это, в сущности, наглядное представление ассемблера. Но я ни разу не слышал, что программировать на ассемблере — легко :) Наоборот, когда я говорю кому-то, что программирую на ассемблере — пусть несколько специфическом, а не x86, многие удивляются и слегка офигевают :)
Кстати, в какой среде это написано? На классический FBD не очень похоже, больше похоже на то, что горячо любимый сименс называет CFC (Continuous function chart).
PS Cлово «вагон» — просто супер :))
Основная проблема — совсем уж бедность такого языка. Высокоуровневый язык с богатыми библиотеками даёт богатые возможности, но требует длительной подготовки. Бедный язык (такой, как FBD) даёт богатые возможности заново переизобрести колесо, велосипед и многое другое :))) И потрахаться на ровном месте с проблемой, о существовании которой даже не догадался бы, работая со старым добрым трубо паскалем или С++.
Короче, золотая середина между богатыми и бедными языками таки есть.
Кажущаяся простота таких языков несколько обманчива — как раз, таки, в силу простоты и минимализма. Разработчику не требуется серьёзной подготовки в плане самого языка, но без алгоритмической подготовки лучше даже не браться.
Скажем так: LAD (ладдер, релейно-контактная логика) и FBD (функциональные диаграммы) — это, в сущности, наглядное представление ассемблера. Но я ни разу не слышал, что программировать на ассемблере — легко :) Наоборот, когда я говорю кому-то, что программирую на ассемблере — пусть несколько специфическом, а не x86, многие удивляются и слегка офигевают :)
Кстати, в какой среде это написано? На классический FBD не очень похоже, больше похоже на то, что горячо любимый сименс называет CFC (Continuous function chart).
PS Cлово «вагон» — просто супер :))
Про среду.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
Это и не FBD. Там есть поддержка типов данных, в том числе структур. Так же данные делятся на потенциальные (мгновенное значение) и команды (буферизуемые значения). Так же имеется встроенная поддержка качества значений. Можно проводить обратные связи, они выделяются зеброй. При этом в качестве начальных значений берутся значения типа данных по умолчанию (прописывается в самом типе).
В общем там вагон всего, еще я планировал впилить туда контроль порядка выполнения в виде связей и поддержку условий. Тогда был бы полный Франкенштейн из FBD, SFC и обычных блок-схем.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
Насчёт бедности (или нет) FBD.
Мне относительно недавно надо было реализовать пересчёт уровня в объём. Ёмкость — цистерна, т.е. горизонтально лежащий цилиндр. Короче, формула получается чуть сложнее, чем 2 х 2. В языке высокого уровня достаточно написать оператор присвоения и формулу справа от него, а на FBD (ну или IL — он же STL по-сименсовски) это реализуется немного заморочнее: загрузить операнды в регистры, выполнить операцию, сохранить результат, следующее действие…
мне это можно не рассказывать, я достаточно хорошо знаком с принципом работы PLC. Не первый год уже… Однако, отечественных изделий побаиваюсь — то, что мне попадалось, было несколько кривым.
А картинки ваши, коллега, очень напоминают мне PCS7 и CFC от Siemens — знакомая штука?
Мне относительно недавно надо было реализовать пересчёт уровня в объём. Ёмкость — цистерна, т.е. горизонтально лежащий цилиндр. Короче, формула получается чуть сложнее, чем 2 х 2. В языке высокого уровня достаточно написать оператор присвоения и формулу справа от него, а на FBD (ну или IL — он же STL по-сименсовски) это реализуется немного заморочнее: загрузить операнды в регистры, выполнить операцию, сохранить результат, следующее действие…
А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов.
мне это можно не рассказывать, я достаточно хорошо знаком с принципом работы PLC. Не первый год уже… Однако, отечественных изделий побаиваюсь — то, что мне попадалось, было несколько кривым.
А картинки ваши, коллега, очень напоминают мне PCS7 и CFC от Siemens — знакомая штука?
В понедельник покажу, как за 5 секунд реализовать пересчет уровня в объем на нашей системе.
А по поводу похожести. Во-первых, если разработчики заглянут сюда, то смогут конкретнее ответить. А во-вторых, развитие АСУ во всем мире движется в одном направлении. Если присмотреться, то все делают одно и тоже и все друг друга «напоминают». «Дьявол» разумеется в деталях и нюансах, но в общем и целом все похоже. И принципы везде одни и те же. А уж если система делается с учетом общепринятых стандартов, то тут и говорить не о чем.
А по поводу похожести. Во-первых, если разработчики заглянут сюда, то смогут конкретнее ответить. А во-вторых, развитие АСУ во всем мире движется в одном направлении. Если присмотреться, то все делают одно и тоже и все друг друга «напоминают». «Дьявол» разумеется в деталях и нюансах, но в общем и целом все похоже. И принципы везде одни и те же. А уж если система делается с учетом общепринятых стандартов, то тут и говорить не о чем.
Беру свои слова обратно.
Вот реализация алгоритма расчета объема воды в баке по уровню:
При этом в расчете я взял радиус бака равный единице и высоту бака (высоту лежащего цилиндра) равную 10.
Действительно в этом случае реализация на ST гораздо проще.
Но это уже скорее расчетная задача.
Но для технологического программирования все таки я уверен, что язык FBD проще и понятнее и нагляднее.
Кстати в нашей среде программирования можно комбинировать языки FBD и ST в любом сочетании. Это я пишу примеры на FBD просто потому, что на языке ST это скучно.
Вот реализация алгоритма расчета объема воды в баке по уровню:
При этом в расчете я взял радиус бака равный единице и высоту бака (высоту лежащего цилиндра) равную 10.
Действительно в этом случае реализация на ST гораздо проще.
Но это уже скорее расчетная задача.
Но для технологического программирования все таки я уверен, что язык FBD проще и понятнее и нагляднее.
Кстати в нашей среде программирования можно комбинировать языки FBD и ST в любом сочетании. Это я пишу примеры на FBD просто потому, что на языке ST это скучно.
Что и требовалось доказать :)
Кстати, приведённая картинка — это не FBD в стантарте IEC (МЭК) 61131-3.
Это самый натуральный CFC (Continuous Function Chart). Он похож на FBD, и, в сущности, это его дальнейшее развитие, но это уже другой, более мощный язык.
На ST (Structured Text, SCL по-сименсовски) это, действительно, реализуется проще всего. Но, при компиляции, это превращается в IL (по-сименсовски ST :) и выглядит примерно так:
Это текст программного блока, который написал я. Естественно, компилятор выдаст что-то, читаемое значительно менее и содержащее большее количество инструкций: немного подумав, я написал этот расчёт так, что мне даже ни разу не пришлось сохранять промежуточный результат расчёта. Для этого пришлось воспользоваться командой TAK, которая выполняет обмен значений между первым и вторым регистрами, а всего регистров два.
Реализовывать подобный расчёт на CFC через кучу блоков совершенно нерационально — куда рациональнее создать отдельный блок на ST (ваш вариант) или IL (мой) и уже его вставить в диаграмму, привязав входные и выходные параметры.
Насчёт того, что
CFC (который вы упорно называете FBD) в ряде случаев намного проще в отладке (и наладке). Как правило, к моменту написания программы есть готовая библиотека типовых блоков (или допиливается в процессе :), таких, как мотор, клапан и т.д. Соответственно, если на запуске объекта всплывают ошибки в работе какого-то конкретного клапана или мотора, по «верёвкам» логических связей довольно просто отследить, откуда что берётся.
Кстати, приведённая картинка — это не FBD в стантарте IEC (МЭК) 61131-3.
Это самый натуральный CFC (Continuous Function Chart). Он похож на FBD, и, в сущности, это его дальнейшее развитие, но это уже другой, более мощный язык.
На ST (Structured Text, SCL по-сименсовски) это, действительно, реализуется проще всего. Но, при компиляции, это превращается в IL (по-сименсовски ST :) и выглядит примерно так:
L #Radius
L #Level
-R // Radius — Level
A OV // error check in substraction operation
JC err
TAK // Preparation to divide: swap ACCUs
/R // (Radius — Level)/Radius
A OV // error check in division operation
JC err
ACOS // Arccosinus
A OV // error check in ACOS operation
JC err
L 2.000000e+000
*R // 2*ACOS((Radius — Level)/Radius)
A OV // error check in multiplication operation
JC err
PUSH // store value in ACCU2
SIN // calculating sinus
A OV // error check in SIN operation
JC err
-R // 2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius))
A OV // error check in substraction operation
JC err
L 2.000000e+000
/R // Divide by 2
A OV // error check in division operation
JC err
L #Radius
SQR // Square, power 2
A OV // error check in power operation
JC err
*R // R*R*(2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius)))/2
A OV // error check in multiplication operation
JC err
L #Length
*R // L*R*R*(2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius)))/2
A OV // error check in multiplication operation
JC err
// Final volume
L 1.000000e+003
/R
A OV // error check in conversion operation
JC err
T #Volume
BEU // if no error stop here
err: L -1.000000e+000 //L#-1 // Returns -1 on error
T #Volume
Это текст программного блока, который написал я. Естественно, компилятор выдаст что-то, читаемое значительно менее и содержащее большее количество инструкций: немного подумав, я написал этот расчёт так, что мне даже ни разу не пришлось сохранять промежуточный результат расчёта. Для этого пришлось воспользоваться командой TAK, которая выполняет обмен значений между первым и вторым регистрами, а всего регистров два.
Реализовывать подобный расчёт на CFC через кучу блоков совершенно нерационально — куда рациональнее создать отдельный блок на ST (ваш вариант) или IL (мой) и уже его вставить в диаграмму, привязав входные и выходные параметры.
Насчёт того, что
я пишу примеры на FBD просто потому, что на языке ST это скучно
CFC (который вы упорно называете FBD) в ряде случаев намного проще в отладке (и наладке). Как правило, к моменту написания программы есть готовая библиотека типовых блоков (или допиливается в процессе :), таких, как мотор, клапан и т.д. Соответственно, если на запуске объекта всплывают ошибки в работе какого-то конкретного клапана или мотора, по «верёвкам» логических связей довольно просто отследить, откуда что берётся.
Я называю FBD по привычке т.к. в предыдущих 6 поколениях КВИНТа язык был куда более похож на FBD, нежели текущая реализация. Но теперь готов поставить везде замену на CFC, хотя это нельзя отнести и к чистому языку CFC.
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
Пусть это не CFC в чистом виде, но от FBD это уже значительно дальше.
В остальном же… Во-первых, не вода, а солярка :) Во-вторых, это не так сложно при наличии некоторого опыта ;)
Siemens предоставляет и IL, и LAD/FBD, и ST, и графические языки. Просто в ряде случаев есть причины ограничиться первыми тремя.
1. они входят в базовый комплект поставки.
2. они не требуют компиляции. А это значит, что в дальнейшем можно сделать upload из контроллера и получить программу в том же виде, а не фарш после компилятора.
Ну и ещё некоторые.
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
А уж переходить с сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
В остальном же… Во-первых, не вода, а солярка :) Во-вторых, это не так сложно при наличии некоторого опыта ;)
Siemens предоставляет и IL, и LAD/FBD, и ST, и графические языки. Просто в ряде случаев есть причины ограничиться первыми тремя.
1. они входят в базовый комплект поставки.
2. они не требуют компиляции. А это значит, что в дальнейшем можно сделать upload из контроллера и получить программу в том же виде, а не фарш после компилятора.
Ну и ещё некоторые.
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
А уж переходить с сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
Не буду говорить ничего про конкурентов, скажу только что у меня выполнение программы с 200 датчиками и 100 механизмов плюс разумеется всевозможная логика в виде блокировок, пересчетов и т.д. укладывается в 5 мсек.
А если «помухлевать» со вставками на ST то можно смело снимать еще 30-40% с времени выполнения.
В общем как показывает практика — стандартный цикл для типового контроллера (разумеется набитого программой) — 10 мсек. Поэтому на счет экономии ресурсов в этом случае даже заморачиваться не стоит.
С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил. Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.
Про стоимость проектов вообще даже приблизительно сравнить не могу.
Хотя с другой стороны — всяк кулик свое болото хвалит. Не удивлюсь, если у них аналогичное мнение на счет преимущества их системы над нашей.
А уж переходить с Сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
Пока не попробуешь — не узнаешь. Хотя с другой стороны я тоже предпочитаю проверенные временем привычные решения, правда при этом все время смотрю на соотношение: риск/выигрыш.
Т.е. если от использования чего то нового выигрыш составляет пару процентов, то действительно игра не стоит свеч. Если что то посущественнее, то уже есть повод задуматься.
Не стоит так делать не потому, что система не уложится в требуемое время цикла. Уложится. Просто не следует делать шаляй-валяй.
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов. Но и косяков хватает, спору нет.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная. По сименсу информации вагон и вся она доступна. По Квинту… ;) Один из показателей надёжности — MTBF (mean time before fault, среднее время наработки на отказ) и у сименса есть таблица MTBF по всем модулям.
Насчёт пробовать — повторюсь, сейчас я делаю проекты в Израиле. Это совершенно ничего не меняет для продукции Siemens и существенно усложняет для Квинта. Хотя бы, потому, что выбор системы далеко не всегда зависит от меня. Да и я к российским системам отношусь с некоторым недоверием: то, с чем сталкивался, пока не впечатлило. Возможно, Квинт лучше :)
С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил.
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов. Но и косяков хватает, спору нет.
Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная. По сименсу информации вагон и вся она доступна. По Квинту… ;) Один из показателей надёжности — MTBF (mean time before fault, среднее время наработки на отказ) и у сименса есть таблица MTBF по всем модулям.
Насчёт пробовать — повторюсь, сейчас я делаю проекты в Израиле. Это совершенно ничего не меняет для продукции Siemens и существенно усложняет для Квинта. Хотя бы, потому, что выбор системы далеко не всегда зависит от меня. Да и я к российским системам отношусь с некоторым недоверием: то, с чем сталкивался, пока не впечатлило. Возможно, Квинт лучше :)
Просто не следует делать шаляй-валяй.
Золотые слова!
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов.
Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная.
У нас тоже есть расчеты надежности, наработки на отказ и т.д. Правда мое мнение заключается в том, что это чисто теоретические цифры типа сферического коня в вакууме. Просто потому, что расчет наработки на отказ во первых не учитывает этап приработки оборудования, когда могут повылазить либо заводские дефекты, либо особенности условий эксплуатации (а они зачастую далеки от идеальных). А во вторых эта некоторая статистическая величина, а как известно: есть ложь, есть большая ложь, а есть статистика.
Поэтому наработка на отказ это конечно хорошо, но практические результаты гораздо нагляднее. Вот могу сказать по нашей системе: 5 лет — полет нормальный.
Что касается информации и ее доступности — ответил в другой ветке. Ответ такой: я не знаю кто и как формирует политику продвижения, пиара и т.п. системы.
Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.
Повторюсь: у сименса столько всего, что заблудиться можно. Из этого есть неприятные следствия:
1. далеко не каждый, кто делает что-то на сименсе — специалист. Я — тоже :)))
2. проекты часто сделаны таки шаляй-валяй… По причине п.1.
У нас тоже есть расчеты надежности, наработки на отказ и т.д. Правда мое мнение заключается в том, что это чисто теоретические цифры типа сферического коня в вакууме.
В случае с сименсом это не только расчёты, но и практические данные тоже. Они ж собирают данные по тем же гарантийным заменам, а S7-300/400 существует уже около 20 лет.
PS «КВИНТ 7» как-то напоминает про STEP 7 и PCS7 :)))
Так это для Ремиконтов? Неплохо развиваются, оказывается, железки. Где про них почитать можно, не подскажете?
Почитать наверное на официальном сайте: www.niiteplopribor.ru
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
Что-то технической документации не нашел, только рекламные брошюры. Все засекречено?
Не думаю, что все засекречено. Единственное — я не работаю с официальной документацией, поэтому имею доступ только ко внутренней рабочей документации. А она скорее всего является коммерческой тайной.
Поэтому по вопросам документации лучше обратиться либо в техподдержку с сайта, либо если кто из имеющих доступ сюда заглянет.
Поэтому по вопросам документации лучше обратиться либо в техподдержку с сайта, либо если кто из имеющих доступ сюда заглянет.
Даже название похоже: Р-400 и S7-400 :)) Посмотрел на сайте — там про КВИНТ 7 совершенно нет информации.
Это чисто совпадение.
Первое поколение контроллеров было Р-100. (сюда входит и легендарный контроллер Р-130)
Потом в КВИНТе 1-4 использовалось второе поколение контроллеров: Р-200.
В КВИНТе 5-6 использовалось третье поколение контроллеров: Р-300.
А сейчас в КВИНТе 7 используется соответственно четвертое поколение контроллеров: Р-400.
Вот и весь секрет в названии.
Первое поколение контроллеров было Р-100. (сюда входит и легендарный контроллер Р-130)
Потом в КВИНТе 1-4 использовалось второе поколение контроллеров: Р-200.
В КВИНТе 5-6 использовалось третье поколение контроллеров: Р-300.
А сейчас в КВИНТе 7 используется соответственно четвертое поколение контроллеров: Р-400.
Вот и весь секрет в названии.
Да шучу я :)
Просто я довольно давно и плотно работаю на сименсовской технике, а сименс таки в лидерах (думаю, никто не будет спорить).
А у сименса вся система называется PCS7/Step7 (сравниваем КВИНТ 7) и контроллеры S7-300/400 (сравниваем Р-300, Р-400) :)) А уж скриншоты CFC редактора так совсем напоминают.
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
Просто я довольно давно и плотно работаю на сименсовской технике, а сименс таки в лидерах (думаю, никто не будет спорить).
А у сименса вся система называется PCS7/Step7 (сравниваем КВИНТ 7) и контроллеры S7-300/400 (сравниваем Р-300, Р-400) :)) А уж скриншоты CFC редактора так совсем напоминают.
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
А вот это уже бооооольшой вопрос!
Шутка.
Хотя с тем, что Сименс в лидерах я спорить точно не буду.
Но вместе с тем мы работаем и с Сименсом. Т.е. можно к сименсовским модулям прикрутить нашу голову, скаду, возможности отображения и архивирования информации. И будет некий КВИНТоСименс!
Прикрутить можно, но не нужно. По одной простой причине…
Допустим, я пишу на сименсе программу в CFC. После того, как я её напишу, я запускаю такую штуку, которая у Siemens называется AS-OS Engineering. Суть в том, что эта программа вытягивает всё, что нужно, из контроллерного проекта и забрасывает его в WinCC — это SCADA от Siemens.
Что это даёт?
В настройках, как вы выразились, алгоблока устанавливаются атрибуты у каждого параметра: задействован ли он в SCADA, требуется ли его архивировать, измеренному значению можно задать единицу измерения.
В общем, 5 минут компиляции и база переменных готова, конфигурация архива готова, аварийные/предупредительные сообщения готовы :)
Допустим, я пишу на сименсе программу в CFC. После того, как я её напишу, я запускаю такую штуку, которая у Siemens называется AS-OS Engineering. Суть в том, что эта программа вытягивает всё, что нужно, из контроллерного проекта и забрасывает его в WinCC — это SCADA от Siemens.
Что это даёт?
В настройках, как вы выразились, алгоблока устанавливаются атрибуты у каждого параметра: задействован ли он в SCADA, требуется ли его архивировать, измеренному значению можно задать единицу измерения.
В общем, 5 минут компиляции и база переменных готова, конфигурация архива готова, аварийные/предупредительные сообщения готовы :)
Ну это уже совсем беспредметный спор.
Я тоже могу в красках описать, как получив от генпроектировщика EXCEL-евский файлик с кксами просто импортирую его в систему и у меня готов набор всех объектов с атрибутами, единицами, диапазонами, архивируемостью и т.д. Короче база готова менее чем за 30 секунд. Остается только красиво расставить алгоблоки в задачах и обвязать «веревками».
В общем везде есть свои плюсы и свои минусы.
Я тоже могу в красках описать, как получив от генпроектировщика EXCEL-евский файлик с кксами просто импортирую его в систему и у меня готов набор всех объектов с атрибутами, единицами, диапазонами, архивируемостью и т.д. Короче база готова менее чем за 30 секунд. Остается только красиво расставить алгоблоки в задачах и обвязать «веревками».
В общем везде есть свои плюсы и свои минусы.
Это не спор, а описание работы. На сайте, который вы привели, про вашу систему документации нет совершенно. А на тот же сименс — её тонны.
Полностью с вами согласен. Проблема в том, что я не в курсе, кто занимается сайтом и какая политика в продвижении системы.
Применительно к сименсу — у них любой мануал и даташит можно найти на сайте, если хорошо поискать. Практически всё, что надо, расписано в документации. Есть даже по-русски. На их сайте есть форум (живой), где можно найти ответы на разные странные вопросы. Есть форум (тоже живой) на сайте российского представительства (по-русски). Есть техподдержка в представительстве и в головной конторе по телефону и e-mail. В головной конторе даже круглосуточно.
А косяки — они у всех есть, и у Сименса тоже. Плюшка в том, что у Сименса хорошо работает техподдержка — следовательно, проблемы решаются.
А косяки — они у всех есть, и у Сименса тоже. Плюшка в том, что у Сименса хорошо работает техподдержка — следовательно, проблемы решаются.
Документация у нас есть полная. Вопрос просто в доступе к ней. Я думаю что она ничуть не хуже сименсовской как по полноте, так и по удобству использования.
Техподдержка также в наличии. Правда на счет круглосуточности ее я не уверен. Но в любом случае — все вопросы оперативно решаются.
А вообще не думаю что есть смысл дальнейшего «меренья» системами, особенно когда в качестве соперника выбирается такой концерн, как Сименс.
Везде есть свои плюсы и свои минусы, а все остальное — работа маркетологов или познается на собственном опыте.
Техподдержка также в наличии. Правда на счет круглосуточности ее я не уверен. Но в любом случае — все вопросы оперативно решаются.
А вообще не думаю что есть смысл дальнейшего «меренья» системами, особенно когда в качестве соперника выбирается такой концерн, как Сименс.
Везде есть свои плюсы и свои минусы, а все остальное — работа маркетологов или познается на собственном опыте.
А кто меряться начал? Кто мне написал
PS Недоступная документация/поддержка = отсутсвию оной. Чтобы это стало понятно, достаточно один раз на объекте в жопе мира в выходные натолкнуться на какой-либо баг, который, на самом деле, фича. Это первое. Второе — исходя из той документации, что есть на сайте, я бы в жизнь не заложил такое оборудование в проект. Ибо чёрный ящик, чернее некуда :)
переходите на нашу разработку!;)у нас есть печеньки!
PS Недоступная документация/поддержка = отсутсвию оной. Чтобы это стало понятно, достаточно один раз на объекте в жопе мира в выходные натолкнуться на какой-либо баг, который, на самом деле, фича. Это первое. Второе — исходя из той документации, что есть на сайте, я бы в жизнь не заложил такое оборудование в проект. Ибо чёрный ящик, чернее некуда :)
Секундочку! По поводу «начал» и «печеньки». Предложение было только в контексте простоты программирования.
Если меня не подводит память и копипаста:
Т.е. суть в том, что программировать проще и быстрее. Причем даже не просто про абстрактное программирование, а конкретно для реализации задачи с баком.
PS...
Критика это хорошо! Я всегда за конструктивную критику т.к. она является сильным подспорьем на пути движения к светлому будущему.
Что касается документации: заказчику передается полный пакет документации в электронном виде. Плюс в бумажном виде еще стопка книг высотой в метр. Так что никто не уходит обиженным.
А вот про отсутствие открытой для всех желающих документации на сайте — еще раз повторю. По этому вопросу ничего сказать не могу т.к. это вне моих компетенций. Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе. Но все течет, все меняется. Кто знает как в будущем жизнь повернется.
Если меня не подводит память и копипаста:
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
Т.е. суть в том, что программировать проще и быстрее. Причем даже не просто про абстрактное программирование, а конкретно для реализации задачи с баком.
Критика это хорошо! Я всегда за конструктивную критику т.к. она является сильным подспорьем на пути движения к светлому будущему.
Что касается документации: заказчику передается полный пакет документации в электронном виде. Плюс в бумажном виде еще стопка книг высотой в метр. Так что никто не уходит обиженным.
А вот про отсутствие открытой для всех желающих документации на сайте — еще раз повторю. По этому вопросу ничего сказать не могу т.к. это вне моих компетенций. Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе. Но все течет, все меняется. Кто знает как в будущем жизнь повернется.
Как говорится, «оправдываешься — значит, виноват» :)))
Сименс даёт такую возможность. Но, по совокупности факторов (включая опыт), одну, отдельно взятую функцию мне было удобнее написать на IL.
Вот это и есть проблема. Лично я (как интегратор, т.е. разработчик проектов по автоматике) не хочу строить автоматику на «чёрном ящике», возможностей, проблем и ограничений которого я не представляю. А получается, что единственный способ познакомиться с вашей техникой — только купить её.
Так я вас и не обвиняю в этом — прекрасно понимаю ситуацию.
И этим компания себя сильно ограничивает. Единственный успешный пример подобной закрытости, который я с ходу припоминаю — Apple. Но это совсем другая история :)
Т.е. суть в том, что программировать проще и быстрее.
Сименс даёт такую возможность. Но, по совокупности факторов (включая опыт), одну, отдельно взятую функцию мне было удобнее написать на IL.
Что касается документации: заказчику передается полный пакет документации в электронном виде.
Вот это и есть проблема. Лично я (как интегратор, т.е. разработчик проектов по автоматике) не хочу строить автоматику на «чёрном ящике», возможностей, проблем и ограничений которого я не представляю. А получается, что единственный способ познакомиться с вашей техникой — только купить её.
По этому вопросу ничего сказать не могу т.к. это вне моих компетенций.
Так я вас и не обвиняю в этом — прекрасно понимаю ситуацию.
Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе.
И этим компания себя сильно ограничивает. Единственный успешный пример подобной закрытости, который я с ходу припоминаю — Apple. Но это совсем другая история :)
И этим компания себя сильно ограничивает.
Не факт. Это просто разные модели развития бизнеса в разных средах. Вы наверное лучше меня знаете о трех основных направлениях в бизнесе. B2B, B2C и B2G.
И если в B2C закрытость действительно является серьезным ограничительным фактором, то в B2G и B2B это не столь критично, т.к. там принципиально другие источники получения информации.
Не буду давать оценку нашей политике в этом направлении просто потому, что не владею необходимой для составления обоснованного собственного мнения информацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небольшая игрушка «Сапер» не в 30 строк