УкраїнськаEnglishmRussian
Вход/Новый
В теме нет новых постов

PLCs programming languages IEC-61131-3 (EN 61131)


Голосование
Вопрос:
Do you need languages IEC 61131-3 implementing for PLC environments based on OpenSCADA?
No, for me DAQ.JavaLikeCalc and DAQ.BlockCalc enough
 
2 из 9 ответов (22%)
Yes, but I cannot to fund for the work
 
2 из 9 ответов (22%)
Yes, and I will help in the adapting and testing
 
4 из 9 ответов (44%)
Yes, and I will fund for the work
 
1 из 9 ответов (11%)


Автор Сообщение
Сообщение создано: 22. 10. 2012 [17:26]
roman
Roman Savochenko
Moderator
Contributor
Developer
Создатель темы
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
Base: actuality and some requests
Funding: Raise: 2300$
Priority: low
State: Fundraising (0%) and actuality polling

IEC 61131-3 is the third part (of 8) of the open international standard IEC 61131 for programmable logic controllers. Part 3 of IEC 61131 deals with programming languages and defines two graphical and two textual PLC programming language standards:
- Ladder diagram (LD), graphical
- Function block diagram (FBD), graphical
- Structured text (ST), textual
- Instruction list (IL), textual
- Sequential function chart (SFC), has elements to organise programs for sequential and parallel control processing.

In OpenSCADA for that and all other the internal DAQ.JavaLikeCalc (textural) and DAQ.BlockCalc (block) languages are used which like to JavaSctipt language and FBD. The PLC environment for OpenSCADA is not the main function then the IEC 61131-3 support is not in priority since its specific and the internal languages DAQ.JavaLikeCalc and DAQ.BlockCalc is more functional, flexible and easier for powerful PLC-environment's functions performing, by OpenSCADA developers mean.

All the work laboriousness evaluation that is:
- Task forming, coordination and organisation: 1HD
- Textual languages (ST, IL): implementing in the module IEC61131 with using the compiled native binaries as the sub-modules of different procedures, that is: the Lexical and Syntax Analyser forms a C-code for each procedure; native gcc compile the C-procedure to a binary module; the module IEC61131 connect the compiled binary sub-module and executing that into the function context and the external requests:
    - Conceptual projecting of the textual languages and a generic implementing mechanisms of call and execution (in an example and only for an one language): 3HD
    - Projecting and implementing of the lexical and syntax analysers (for one languages): 2x4HD
    - Testing, stabilising and following support/extending: 2x5HD
- Graphical languages (LD, FBD, SFC): execution implementing in DAQ.BlockCalc, but they visual development in UI.Vision (potentially in UI.WebVision):
    - Conceptual projecting of the interface of developing and controlling the execution between DAQ.BlockCalc and UI.Vision for the graphical languages (in an example and only for an one language): 1.5HD
    - Implementing in UI.Vision for the developing and execution the scheme interface in DAQ.BlockCalc (in an example and only for an one language): 2HD
    - Forming of the functions library (for DAQ.BlockCalc) and the visual shapes library of that functions (UI.Vision) (for one languages): 3x2HD
    - Testing, stabilising and following support/extending: 3x5HD

Summary, we have the minimal complexity per one textual it is 13HD and one graphical language it is 11.5HD and the fundraising level to the task start it is 2300$.

Learn, learn and learn better than work, work and work.
Сообщение создано: 18. 12. 2012 [07:47]
Gregory
Григорий Рубцов
Зарегистрирован(а) с: 12.12.2012
Сообщения: 4
Популярность языков стандарта МЭК 61131-3 стремительно растёт. Всё большее число OEM-производителей внедряют в свои ПЛК и промышленные компьютеры поддержку этого стандарта. Поэтому для того чтобы OpenSCADA оставалась конкурентоспособной ей определённо имеет смысл поддерживать эти языки программирования.
Сообщение создано: 18. 12. 2012 [11:26]
roman
Roman Savochenko
Moderator
Contributor
Developer
Создатель темы
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
"Gregory" wrote:

Популярность языков стандарта МЭК 61131-3 стремительно растёт. Всё большее число OEM-производителей внедряют в свои ПЛК и промышленные компьютеры поддержку этого стандарта. Поэтому для того чтобы OpenSCADA оставалась конкурентоспособной ей определённо имеет смысл поддерживать эти языки программирования.

Вовсе неопределённо и именно для этого создан данный опрос/сбор средств. К вашему сведению этот набор языков для узкоспециализированного класса "слабых" контроллеров, которые в значительной степени уже вытеснены нормальными ПЛК, способными исполнять полноценные ОС и для которых такие языки просто ограничивают возможности современного железа. Следовательно широкое распространение МЭК 61131-3 это чисто субъективное мнение и про конкурентноспособность OpenSCADA, которая ни разу не рыночное решение, а свободный проект, тут не нужно!

Однако если кому это действительно нужно то он и профинансирует работу по реализации языков этого стандарта, а не будет кивать в сторону разработчиков OpenSCADA, которым это лично не нужно.

Learn, learn and learn better than work, work and work.
Сообщение создано: 19. 09. 2019 [12:04]
RehDen
Денис АДА
Зарегистрирован(а) с: 19.09.2019
Сообщения: 1
"roman" wrote:

"Gregory" wrote:

Популярность языков стандарта МЭК 61131-3 стремительно растёт. Всё большее число OEM-производителей внедряют в свои ПЛК и промышленные компьютеры поддержку этого стандарта. Поэтому для того чтобы OpenSCADA оставалась конкурентоспособной ей определённо имеет смысл поддерживать эти языки программирования.

Вовсе неопределённо и именно для этого создан данный опрос/сбор средств. К вашему сведению этот набор языков для узкоспециализированного класса "слабых" контроллеров, которые в значительной степени уже вытеснены нормальными ПЛК, способными исполнять полноценные ОС и для которых такие языки просто ограничивают возможности современного железа. Следовательно широкое распространение МЭК 61131-3 это чисто субъективное мнение и про конкурентноспособность OpenSCADA, которая ни разу не рыночное решение, а свободный проект, тут не нужно!

Однако если кому это действительно нужно то он и профинансирует работу по реализации языков этого стандарта, а не будет кивать в сторону разработчиков OpenSCADA, которым это лично не нужно.

Всем привет.
В поисках доступного решения для реализации своих хотелок наткнулся на ваш проект. С первого раза мне не получилось понять его. вообще ни как. Хотя у меня стаж 9 лет работы со скада системами и плк контроллерами. после чего почитав форумы понял что нужно больше времени чтобы освоить вашу систему. В итоге мне она даже понравилась. и сейчас я ее активно изучаю. Конечно очень не привычно но все таки получается. И действительно как многие сказали демо проекты не для освоения скады новичками. новички и дальше установки не пролезут =)) но эт чисто мое мнение. В процессе изучения я понимаю что система может работать и как контроллер. пытаюсь разобраться что к чему и понимаю - это очень сложная задача. спросите в плане чего она сложная. в плане отладки. создать более менее сложный какой то алгоритм, а потом его отладить будет очень сложно и может даже не возможно. все загвоздка в том что всю картину не видно и нужно ее держать в голове. прямых переходов нету. нужно все искать и открывать.
И после чего начинаю искать стороннее решение по программирования на языках IEC-61131-3. Кое что нашел... но все имеют кучу недостатков. я рассматривал только бесплатные решения. и еще было условие - исполнение на компе (SoftPLC) с поддержкой modbus. эт чтобы с вашей системой состыковать =))
Сам работаю в основном с платформами Simens Step 7 и tia portal, а также приходится программировать и другие фирмы Mitsubishi, Omron, ОВЕН, ален брэдли. так вот во всех редакторах програм плк этих фирм присутствуют изыки стандарта IEC-61131-3 и все они имеют функцию мониторинга. что позволяет с легкостью отслеживать и отлаживать программы на рабочем оборудовании и при симуляции.
А это сообщение я решил написать когда увидел ваш пост от 18. 12. 2012 в котором вы говорите что эти языки все меньше и меньше используются. И честно говоря меня это очень разочаровало. сегодня на дворе уже 19 год подходит к концу и я смею утверждать что эти языки очень широко используются в системах автоматизации на миллионах объектах. включая не только промышленность. Даже программирование на ардуино стремятся перевести на подобные языки. но как я и говорил нормально работают такие языки не у всех. не имея обратной связи по исполнению программы, то-есть отображения прохождения сигналов, очень сложно отлаживать ее. маленькие алгоритмы не беру в счет.
Конечно бы очень хотелось чтобы в вашем продукте появилась полноценная поддержка этих языков с обратной связью по исполнению. но в силу осознавания сколько на это потребуется сил и времени я не вправе что то даже просить не то что требовать =))
Может есть возможность адаптировать уже какие то готовые открытые проекты. к примеру мне понравилась реализация программой среды OpenPLC Editor проекта OpenPLC. я протестировал FBD и он работает как нужно. Отображаются и битовые и числовые переменные. все бы хорошо но это только в режиме симуляции. среда исполнения контроллера на отдельном модуле. и требует отдельного компилированного файла из OpenPLC Editor. и конечно же реальное положение вещей не увидеть. если можно их как то связать бы ло бы превосходно. но это так мысли в слух. я то да же не представляю как там что работает на низком уровне.
На данный момент я решил попробовать внедрить OpenSCADA на предприятии на котором сейчас работаю. Пока только в качестве станций визуализации и архивации. без каких либо алгоритмов взаимодействия или управления.
И в заключении еще раз хотелось бы вас поблагодарить за систему. если у меня с ней отношения срастутся то буду ее активно использовать и продвигать со всеми вытекающими благодарностями и помощью.



8091