Comments 38
Вагон — это пять!
По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете.
+2
UFO just landed and posted this here
А с чем вы не согласны?
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
0
Да уж, действительно, легко и весело :) Примерно, как сложить слово «вечность» из приведённых кубиков :))
Основная проблема — совсем уж бедность такого языка. Высокоуровневый язык с богатыми библиотеками даёт богатые возможности, но требует длительной подготовки. Бедный язык (такой, как FBD) даёт богатые возможности заново переизобрести колесо, велосипед и многое другое :))) И потрахаться на ровном месте с проблемой, о существовании которой даже не догадался бы, работая со старым добрым трубо паскалем или С++.
Короче, золотая середина между богатыми и бедными языками таки есть.
Кажущаяся простота таких языков несколько обманчива — как раз, таки, в силу простоты и минимализма. Разработчику не требуется серьёзной подготовки в плане самого языка, но без алгоритмической подготовки лучше даже не браться.
Скажем так: LAD (ладдер, релейно-контактная логика) и FBD (функциональные диаграммы) — это, в сущности, наглядное представление ассемблера. Но я ни разу не слышал, что программировать на ассемблере — легко :) Наоборот, когда я говорю кому-то, что программирую на ассемблере — пусть несколько специфическом, а не x86, многие удивляются и слегка офигевают :)
Кстати, в какой среде это написано? На классический FBD не очень похоже, больше похоже на то, что горячо любимый сименс называет CFC (Continuous function chart).
PS Cлово «вагон» — просто супер :))
Основная проблема — совсем уж бедность такого языка. Высокоуровневый язык с богатыми библиотеками даёт богатые возможности, но требует длительной подготовки. Бедный язык (такой, как FBD) даёт богатые возможности заново переизобрести колесо, велосипед и многое другое :))) И потрахаться на ровном месте с проблемой, о существовании которой даже не догадался бы, работая со старым добрым трубо паскалем или С++.
Короче, золотая середина между богатыми и бедными языками таки есть.
Кажущаяся простота таких языков несколько обманчива — как раз, таки, в силу простоты и минимализма. Разработчику не требуется серьёзной подготовки в плане самого языка, но без алгоритмической подготовки лучше даже не браться.
Скажем так: LAD (ладдер, релейно-контактная логика) и FBD (функциональные диаграммы) — это, в сущности, наглядное представление ассемблера. Но я ни разу не слышал, что программировать на ассемблере — легко :) Наоборот, когда я говорю кому-то, что программирую на ассемблере — пусть несколько специфическом, а не x86, многие удивляются и слегка офигевают :)
Кстати, в какой среде это написано? На классический FBD не очень похоже, больше похоже на то, что горячо любимый сименс называет CFC (Continuous function chart).
PS Cлово «вагон» — просто супер :))
0
Про среду.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
Это и не FBD. Там есть поддержка типов данных, в том числе структур. Так же данные делятся на потенциальные (мгновенное значение) и команды (буферизуемые значения). Так же имеется встроенная поддержка качества значений. Можно проводить обратные связи, они выделяются зеброй. При этом в качестве начальных значений берутся значения типа данных по умолчанию (прописывается в самом типе).
В общем там вагон всего, еще я планировал впилить туда контроль порядка выполнения в виде связей и поддержку условий. Тогда был бы полный Франкенштейн из FBD, SFC и обычных блок-схем.
Вот слова одного из главных разработчиков среды.
Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.
Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.
С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.
Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
0
Насчёт бедности (или нет) FBD.
Мне относительно недавно надо было реализовать пересчёт уровня в объём. Ёмкость — цистерна, т.е. горизонтально лежащий цилиндр. Короче, формула получается чуть сложнее, чем 2 х 2. В языке высокого уровня достаточно написать оператор присвоения и формулу справа от него, а на FBD (ну или IL — он же STL по-сименсовски) это реализуется немного заморочнее: загрузить операнды в регистры, выполнить операцию, сохранить результат, следующее действие…
мне это можно не рассказывать, я достаточно хорошо знаком с принципом работы PLC. Не первый год уже… Однако, отечественных изделий побаиваюсь — то, что мне попадалось, было несколько кривым.
А картинки ваши, коллега, очень напоминают мне PCS7 и CFC от Siemens — знакомая штука?
Мне относительно недавно надо было реализовать пересчёт уровня в объём. Ёмкость — цистерна, т.е. горизонтально лежащий цилиндр. Короче, формула получается чуть сложнее, чем 2 х 2. В языке высокого уровня достаточно написать оператор присвоения и формулу справа от него, а на FBD (ну или IL — он же STL по-сименсовски) это реализуется немного заморочнее: загрузить операнды в регистры, выполнить операцию, сохранить результат, следующее действие…
А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов.
мне это можно не рассказывать, я достаточно хорошо знаком с принципом работы PLC. Не первый год уже… Однако, отечественных изделий побаиваюсь — то, что мне попадалось, было несколько кривым.
А картинки ваши, коллега, очень напоминают мне PCS7 и CFC от Siemens — знакомая штука?
0
В понедельник покажу, как за 5 секунд реализовать пересчет уровня в объем на нашей системе.
А по поводу похожести. Во-первых, если разработчики заглянут сюда, то смогут конкретнее ответить. А во-вторых, развитие АСУ во всем мире движется в одном направлении. Если присмотреться, то все делают одно и тоже и все друг друга «напоминают». «Дьявол» разумеется в деталях и нюансах, но в общем и целом все похоже. И принципы везде одни и те же. А уж если система делается с учетом общепринятых стандартов, то тут и говорить не о чем.
А по поводу похожести. Во-первых, если разработчики заглянут сюда, то смогут конкретнее ответить. А во-вторых, развитие АСУ во всем мире движется в одном направлении. Если присмотреться, то все делают одно и тоже и все друг друга «напоминают». «Дьявол» разумеется в деталях и нюансах, но в общем и целом все похоже. И принципы везде одни и те же. А уж если система делается с учетом общепринятых стандартов, то тут и говорить не о чем.
0
Беру свои слова обратно.
Вот реализация алгоритма расчета объема воды в баке по уровню:
При этом в расчете я взял радиус бака равный единице и высоту бака (высоту лежащего цилиндра) равную 10.
Действительно в этом случае реализация на ST гораздо проще.
Но это уже скорее расчетная задача.
Но для технологического программирования все таки я уверен, что язык FBD проще и понятнее и нагляднее.
Кстати в нашей среде программирования можно комбинировать языки FBD и ST в любом сочетании. Это я пишу примеры на FBD просто потому, что на языке ST это скучно.
Вот реализация алгоритма расчета объема воды в баке по уровню:
При этом в расчете я взял радиус бака равный единице и высоту бака (высоту лежащего цилиндра) равную 10.
Действительно в этом случае реализация на ST гораздо проще.
Но это уже скорее расчетная задача.
Но для технологического программирования все таки я уверен, что язык FBD проще и понятнее и нагляднее.
Кстати в нашей среде программирования можно комбинировать языки FBD и ST в любом сочетании. Это я пишу примеры на FBD просто потому, что на языке ST это скучно.
0
Что и требовалось доказать :)
Кстати, приведённая картинка — это не 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) в ряде случаев намного проще в отладке (и наладке). Как правило, к моменту написания программы есть готовая библиотека типовых блоков (или допиливается в процессе :), таких, как мотор, клапан и т.д. Соответственно, если на запуске объекта всплывают ошибки в работе какого-то конкретного клапана или мотора, по «верёвкам» логических связей довольно просто отследить, откуда что берётся.
0
Я называю FBD по привычке т.к. в предыдущих 6 поколениях КВИНТа язык был куда более похож на FBD, нежели текущая реализация. Но теперь готов поставить везде замену на CFC, хотя это нельзя отнести и к чистому языку CFC.
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
0
Пусть это не CFC в чистом виде, но от FBD это уже значительно дальше.
В остальном же… Во-первых, не вода, а солярка :) Во-вторых, это не так сложно при наличии некоторого опыта ;)
Siemens предоставляет и IL, и LAD/FBD, и ST, и графические языки. Просто в ряде случаев есть причины ограничиться первыми тремя.
1. они входят в базовый комплект поставки.
2. они не требуют компиляции. А это значит, что в дальнейшем можно сделать upload из контроллера и получить программу в том же виде, а не фарш после компилятора.
Ну и ещё некоторые.
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
А уж переходить с сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
В остальном же… Во-первых, не вода, а солярка :) Во-вторых, это не так сложно при наличии некоторого опыта ;)
Siemens предоставляет и IL, и LAD/FBD, и ST, и графические языки. Просто в ряде случаев есть причины ограничиться первыми тремя.
1. они входят в базовый комплект поставки.
2. они не требуют компиляции. А это значит, что в дальнейшем можно сделать upload из контроллера и получить программу в том же виде, а не фарш после компилятора.
Ну и ещё некоторые.
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
А уж переходить с сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
0
Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)
Не буду говорить ничего про конкурентов, скажу только что у меня выполнение программы с 200 датчиками и 100 механизмов плюс разумеется всевозможная логика в виде блокировок, пересчетов и т.д. укладывается в 5 мсек.
А если «помухлевать» со вставками на ST то можно смело снимать еще 30-40% с времени выполнения.
В общем как показывает практика — стандартный цикл для типового контроллера (разумеется набитого программой) — 10 мсек. Поэтому на счет экономии ресурсов в этом случае даже заморачиваться не стоит.
С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил. Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.
Про стоимость проектов вообще даже приблизительно сравнить не могу.
Хотя с другой стороны — всяк кулик свое болото хвалит. Не удивлюсь, если у них аналогичное мнение на счет преимущества их системы над нашей.
А уж переходить с Сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
Пока не попробуешь — не узнаешь. Хотя с другой стороны я тоже предпочитаю проверенные временем привычные решения, правда при этом все время смотрю на соотношение: риск/выигрыш.
Т.е. если от использования чего то нового выигрыш составляет пару процентов, то действительно игра не стоит свеч. Если что то посущественнее, то уже есть повод задуматься.
0
Не стоит так делать не потому, что система не уложится в требуемое время цикла. Уложится. Просто не следует делать шаляй-валяй.
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов. Но и косяков хватает, спору нет.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная. По сименсу информации вагон и вся она доступна. По Квинту… ;) Один из показателей надёжности — MTBF (mean time before fault, среднее время наработки на отказ) и у сименса есть таблица MTBF по всем модулям.
Насчёт пробовать — повторюсь, сейчас я делаю проекты в Израиле. Это совершенно ничего не меняет для продукции Siemens и существенно усложняет для Квинта. Хотя бы, потому, что выбор системы далеко не всегда зависит от меня. Да и я к российским системам отношусь с некоторым недоверием: то, с чем сталкивался, пока не впечатлило. Возможно, Квинт лучше :)
С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил.
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов. Но и косяков хватает, спору нет.
Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная. По сименсу информации вагон и вся она доступна. По Квинту… ;) Один из показателей надёжности — MTBF (mean time before fault, среднее время наработки на отказ) и у сименса есть таблица MTBF по всем модулям.
Насчёт пробовать — повторюсь, сейчас я делаю проекты в Израиле. Это совершенно ничего не меняет для продукции Siemens и существенно усложняет для Квинта. Хотя бы, потому, что выбор системы далеко не всегда зависит от меня. Да и я к российским системам отношусь с некоторым недоверием: то, с чем сталкивался, пока не впечатлило. Возможно, Квинт лучше :)
0
Просто не следует делать шаляй-валяй.
Золотые слова!
Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов.
Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.
Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная.
У нас тоже есть расчеты надежности, наработки на отказ и т.д. Правда мое мнение заключается в том, что это чисто теоретические цифры типа сферического коня в вакууме. Просто потому, что расчет наработки на отказ во первых не учитывает этап приработки оборудования, когда могут повылазить либо заводские дефекты, либо особенности условий эксплуатации (а они зачастую далеки от идеальных). А во вторых эта некоторая статистическая величина, а как известно: есть ложь, есть большая ложь, а есть статистика.
Поэтому наработка на отказ это конечно хорошо, но практические результаты гораздо нагляднее. Вот могу сказать по нашей системе: 5 лет — полет нормальный.
Что касается информации и ее доступности — ответил в другой ветке. Ответ такой: я не знаю кто и как формирует политику продвижения, пиара и т.п. системы.
0
Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.
Повторюсь: у сименса столько всего, что заблудиться можно. Из этого есть неприятные следствия:
1. далеко не каждый, кто делает что-то на сименсе — специалист. Я — тоже :)))
2. проекты часто сделаны таки шаляй-валяй… По причине п.1.
У нас тоже есть расчеты надежности, наработки на отказ и т.д. Правда мое мнение заключается в том, что это чисто теоретические цифры типа сферического коня в вакууме.
В случае с сименсом это не только расчёты, но и практические данные тоже. Они ж собирают данные по тем же гарантийным заменам, а S7-300/400 существует уже около 20 лет.
0
И КВИНТ тоже существует уже 20 лет. Правда за эти двадцать лет сменилось 3 принципиально разных поколения. Но есть проекты, реализованные в конце девяностых, которые работают до сих пор.
0
PS «КВИНТ 7» как-то напоминает про STEP 7 и PCS7 :)))
0
Так это для Ремиконтов? Неплохо развиваются, оказывается, железки. Где про них почитать можно, не подскажете?
0
Почитать наверное на официальном сайте: www.niiteplopribor.ru
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
0
Что-то технической документации не нашел, только рекламные брошюры. Все засекречено?
0
Не думаю, что все засекречено. Единственное — я не работаю с официальной документацией, поэтому имею доступ только ко внутренней рабочей документации. А она скорее всего является коммерческой тайной.
Поэтому по вопросам документации лучше обратиться либо в техподдержку с сайта, либо если кто из имеющих доступ сюда заглянет.
Поэтому по вопросам документации лучше обратиться либо в техподдержку с сайта, либо если кто из имеющих доступ сюда заглянет.
0
Даже название похоже: Р-400 и S7-400 :)) Посмотрел на сайте — там про КВИНТ 7 совершенно нет информации.
0
Это чисто совпадение.
Первое поколение контроллеров было Р-100. (сюда входит и легендарный контроллер Р-130)
Потом в КВИНТе 1-4 использовалось второе поколение контроллеров: Р-200.
В КВИНТе 5-6 использовалось третье поколение контроллеров: Р-300.
А сейчас в КВИНТе 7 используется соответственно четвертое поколение контроллеров: Р-400.
Вот и весь секрет в названии.
Первое поколение контроллеров было Р-100. (сюда входит и легендарный контроллер Р-130)
Потом в КВИНТе 1-4 использовалось второе поколение контроллеров: Р-200.
В КВИНТе 5-6 использовалось третье поколение контроллеров: Р-300.
А сейчас в КВИНТе 7 используется соответственно четвертое поколение контроллеров: Р-400.
Вот и весь секрет в названии.
0
Да шучу я :)
Просто я довольно давно и плотно работаю на сименсовской технике, а сименс таки в лидерах (думаю, никто не будет спорить).
А у сименса вся система называется PCS7/Step7 (сравниваем КВИНТ 7) и контроллеры S7-300/400 (сравниваем Р-300, Р-400) :)) А уж скриншоты CFC редактора так совсем напоминают.
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
Просто я довольно давно и плотно работаю на сименсовской технике, а сименс таки в лидерах (думаю, никто не будет спорить).
А у сименса вся система называется PCS7/Step7 (сравниваем КВИНТ 7) и контроллеры S7-300/400 (сравниваем Р-300, Р-400) :)) А уж скриншоты CFC редактора так совсем напоминают.
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
0
И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
А вот это уже бооооольшой вопрос!
Шутка.
Хотя с тем, что Сименс в лидерах я спорить точно не буду.
Но вместе с тем мы работаем и с Сименсом. Т.е. можно к сименсовским модулям прикрутить нашу голову, скаду, возможности отображения и архивирования информации. И будет некий КВИНТоСименс!
0
Прикрутить можно, но не нужно. По одной простой причине…
Допустим, я пишу на сименсе программу в CFC. После того, как я её напишу, я запускаю такую штуку, которая у Siemens называется AS-OS Engineering. Суть в том, что эта программа вытягивает всё, что нужно, из контроллерного проекта и забрасывает его в WinCC — это SCADA от Siemens.
Что это даёт?
В настройках, как вы выразились, алгоблока устанавливаются атрибуты у каждого параметра: задействован ли он в SCADA, требуется ли его архивировать, измеренному значению можно задать единицу измерения.
В общем, 5 минут компиляции и база переменных готова, конфигурация архива готова, аварийные/предупредительные сообщения готовы :)
Допустим, я пишу на сименсе программу в CFC. После того, как я её напишу, я запускаю такую штуку, которая у Siemens называется AS-OS Engineering. Суть в том, что эта программа вытягивает всё, что нужно, из контроллерного проекта и забрасывает его в WinCC — это SCADA от Siemens.
Что это даёт?
В настройках, как вы выразились, алгоблока устанавливаются атрибуты у каждого параметра: задействован ли он в SCADA, требуется ли его архивировать, измеренному значению можно задать единицу измерения.
В общем, 5 минут компиляции и база переменных готова, конфигурация архива готова, аварийные/предупредительные сообщения готовы :)
0
Ну это уже совсем беспредметный спор.
Я тоже могу в красках описать, как получив от генпроектировщика EXCEL-евский файлик с кксами просто импортирую его в систему и у меня готов набор всех объектов с атрибутами, единицами, диапазонами, архивируемостью и т.д. Короче база готова менее чем за 30 секунд. Остается только красиво расставить алгоблоки в задачах и обвязать «веревками».
В общем везде есть свои плюсы и свои минусы.
Я тоже могу в красках описать, как получив от генпроектировщика EXCEL-евский файлик с кксами просто импортирую его в систему и у меня готов набор всех объектов с атрибутами, единицами, диапазонами, архивируемостью и т.д. Короче база готова менее чем за 30 секунд. Остается только красиво расставить алгоблоки в задачах и обвязать «веревками».
В общем везде есть свои плюсы и свои минусы.
0
Это не спор, а описание работы. На сайте, который вы привели, про вашу систему документации нет совершенно. А на тот же сименс — её тонны.
+1
Полностью с вами согласен. Проблема в том, что я не в курсе, кто занимается сайтом и какая политика в продвижении системы.
0
Применительно к сименсу — у них любой мануал и даташит можно найти на сайте, если хорошо поискать. Практически всё, что надо, расписано в документации. Есть даже по-русски. На их сайте есть форум (живой), где можно найти ответы на разные странные вопросы. Есть форум (тоже живой) на сайте российского представительства (по-русски). Есть техподдержка в представительстве и в головной конторе по телефону и e-mail. В головной конторе даже круглосуточно.
А косяки — они у всех есть, и у Сименса тоже. Плюшка в том, что у Сименса хорошо работает техподдержка — следовательно, проблемы решаются.
А косяки — они у всех есть, и у Сименса тоже. Плюшка в том, что у Сименса хорошо работает техподдержка — следовательно, проблемы решаются.
0
Документация у нас есть полная. Вопрос просто в доступе к ней. Я думаю что она ничуть не хуже сименсовской как по полноте, так и по удобству использования.
Техподдержка также в наличии. Правда на счет круглосуточности ее я не уверен. Но в любом случае — все вопросы оперативно решаются.
А вообще не думаю что есть смысл дальнейшего «меренья» системами, особенно когда в качестве соперника выбирается такой концерн, как Сименс.
Везде есть свои плюсы и свои минусы, а все остальное — работа маркетологов или познается на собственном опыте.
Техподдержка также в наличии. Правда на счет круглосуточности ее я не уверен. Но в любом случае — все вопросы оперативно решаются.
А вообще не думаю что есть смысл дальнейшего «меренья» системами, особенно когда в качестве соперника выбирается такой концерн, как Сименс.
Везде есть свои плюсы и свои минусы, а все остальное — работа маркетологов или познается на собственном опыте.
0
А кто меряться начал? Кто мне написал
PS Недоступная документация/поддержка = отсутсвию оной. Чтобы это стало понятно, достаточно один раз на объекте в жопе мира в выходные натолкнуться на какой-либо баг, который, на самом деле, фича. Это первое. Второе — исходя из той документации, что есть на сайте, я бы в жизнь не заложил такое оборудование в проект. Ибо чёрный ящик, чернее некуда :)
переходите на нашу разработку!;)у нас есть печеньки!
PS Недоступная документация/поддержка = отсутсвию оной. Чтобы это стало понятно, достаточно один раз на объекте в жопе мира в выходные натолкнуться на какой-либо баг, который, на самом деле, фича. Это первое. Второе — исходя из той документации, что есть на сайте, я бы в жизнь не заложил такое оборудование в проект. Ибо чёрный ящик, чернее некуда :)
0
Секундочку! По поводу «начал» и «печеньки». Предложение было только в контексте простоты программирования.
Если меня не подводит память и копипаста:
Т.е. суть в том, что программировать проще и быстрее. Причем даже не просто про абстрактное программирование, а конкретно для реализации задачи с баком.
PS...
Критика это хорошо! Я всегда за конструктивную критику т.к. она является сильным подспорьем на пути движения к светлому будущему.
Что касается документации: заказчику передается полный пакет документации в электронном виде. Плюс в бумажном виде еще стопка книг высотой в метр. Так что никто не уходит обиженным.
А вот про отсутствие открытой для всех желающих документации на сайте — еще раз повторю. По этому вопросу ничего сказать не могу т.к. это вне моих компетенций. Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе. Но все течет, все меняется. Кто знает как в будущем жизнь повернется.
Если меня не подводит память и копипаста:
По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
Т.е. суть в том, что программировать проще и быстрее. Причем даже не просто про абстрактное программирование, а конкретно для реализации задачи с баком.
Критика это хорошо! Я всегда за конструктивную критику т.к. она является сильным подспорьем на пути движения к светлому будущему.
Что касается документации: заказчику передается полный пакет документации в электронном виде. Плюс в бумажном виде еще стопка книг высотой в метр. Так что никто не уходит обиженным.
А вот про отсутствие открытой для всех желающих документации на сайте — еще раз повторю. По этому вопросу ничего сказать не могу т.к. это вне моих компетенций. Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе. Но все течет, все меняется. Кто знает как в будущем жизнь повернется.
0
Как говорится, «оправдываешься — значит, виноват» :)))
Сименс даёт такую возможность. Но, по совокупности факторов (включая опыт), одну, отдельно взятую функцию мне было удобнее написать на IL.
Вот это и есть проблема. Лично я (как интегратор, т.е. разработчик проектов по автоматике) не хочу строить автоматику на «чёрном ящике», возможностей, проблем и ограничений которого я не представляю. А получается, что единственный способ познакомиться с вашей техникой — только купить её.
Так я вас и не обвиняю в этом — прекрасно понимаю ситуацию.
И этим компания себя сильно ограничивает. Единственный успешный пример подобной закрытости, который я с ходу припоминаю — Apple. Но это совсем другая история :)
Т.е. суть в том, что программировать проще и быстрее.
Сименс даёт такую возможность. Но, по совокупности факторов (включая опыт), одну, отдельно взятую функцию мне было удобнее написать на IL.
Что касается документации: заказчику передается полный пакет документации в электронном виде.
Вот это и есть проблема. Лично я (как интегратор, т.е. разработчик проектов по автоматике) не хочу строить автоматику на «чёрном ящике», возможностей, проблем и ограничений которого я не представляю. А получается, что единственный способ познакомиться с вашей техникой — только купить её.
По этому вопросу ничего сказать не могу т.к. это вне моих компетенций.
Так я вас и не обвиняю в этом — прекрасно понимаю ситуацию.
Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе.
И этим компания себя сильно ограничивает. Единственный успешный пример подобной закрытости, который я с ходу припоминаю — Apple. Но это совсем другая история :)
0
И этим компания себя сильно ограничивает.
Не факт. Это просто разные модели развития бизнеса в разных средах. Вы наверное лучше меня знаете о трех основных направлениях в бизнесе. B2B, B2C и B2G.
И если в B2C закрытость действительно является серьезным ограничительным фактором, то в B2G и B2B это не столь критично, т.к. там принципиально другие источники получения информации.
Не буду давать оценку нашей политике в этом направлении просто потому, что не владею необходимой для составления обоснованного собственного мнения информацией.
0
Sign up to leave a comment.
Небольшая игрушка «Сапер» не в 30 строк