| Author |
Message |
|
Written on: 03. 08. 2009 [00:19]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
kuzulis wrote:
1. Графический редактор блочных схем
имеете ввиду нечто типа FBD ?
Да, но не только. Наверно больше как язык графического программирования VI (Virtual Instruments) LabVIEW.
Хотелось бы разработать графический язык программирования для OpenSCADA. Начать, наверно, стоит именно с выбора стандарта. Для FBD есть IEC 61131-3. Для VI вроде конкретного стандарта нет.
Если это будет сделано OpenSCADA можно преподнести миру не как SCADA-систему, а как Среду программирования для инженеров и ученых (в каком-то интервью Роман даже не отрицал возможности переименования проекта).
Готов вложить ради этого все свои свободные ресурсы (и не только свои).
P.S. Еще как вариант язык графического программирования UML, стандартизован, имеет наработки и целые проекты Open Source.
[This article was edited 1 times, at last 03.08.2009 at 08:36.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 03. 08. 2009 [12:53]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
almaz wrote:
Чего не хватает (по моему мнению) для удобства пользователя:
1. Графический редактор блочных схем
Думаю в этом месяце доберусь и сделаю на основе Vision такой редактор.
almaz wrote:
2. Группы в дереве проекта (уровень вложенности жестко задан)
Смотря где. Для проекта не жёстко, а для библиотек жёстко. Для библиотек не вижу особого смысла делать иерархически, да и сложнее это.
Как насчёт переименовать "Контроллеры" в "Устройства"?
Learn, learn and learn better than work, work and work.
|
|
Written on: 03. 08. 2009 [13:30]
|
|
kuzulis
Денис Шиенков
registered since: 10.07.2009
Posts: 128
|
Как насчёт переименовать "Контроллеры" в "Устройства"?
а смотря что за контроллеры.. если под ними подразумеваются устройства в сети - то лучще их обозвать "узлами" .. т.к. это более абстрактно..
а если под "контроллерами" имеется ввиду нечто логическое внутри самой СКАДА - то хз как это назвать.. 
|
|
Written on: 03. 08. 2009 [13:39]
|
|
kuzulis
Денис Шиенков
registered since: 10.07.2009
Posts: 128
|
и не лучше ли посмотреть на такую иерархию (применительно к Modbus например):
для части протокола , работающего через последовательные устройства сделать такую иерархию к примеру:
1. Канал - это собственно сам последовательный порт + его парметры + т.п... в канале может быть много узлов (до 30 хотя в теории 247 )
2. Узел - это собственно само модбас у-во , со своими параметрами... содержит много точек.. под точками понимаются регистры
3. Точка - это собствено какой-то регистр устройства
для части TCP протокола тоже сделать нечто похожее:
1. Канал - это определенный сокет, в котором может быть много устройств, имеет такие параметры как IP адрес и порт
2. Узел - адрес модбас устройства ( это поле UID в MBHAP)
3. точка
Аналогичную иерархию думаю можно сделать и для других протоколов обмена
|
|
Written on: 03. 08. 2009 [14:15]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
roman wrote:
Думаю в этом месяце доберусь и сделаю на основе Vision такой редактор.
Ура! Да свершится! А концепция языка графического программирования будет? Все-таки что будет браться за основу? FBD, VI или UML?
Листы (страницы) - это контроллеры блочного вычислителя?
На листы накидываются три составляющие: переменные (с логического уровня, параметры блочного вычислителя), функции (блоки блочного вычислителя), связи. Куча вопросов...
roman wrote:
Смотря где. Для проекта не жёстко, а для библиотек жёстко. Для библиотек не вижу особого смысла делать иерархически, да и сложнее это.
А названия библиотек и так неплохо выполняют функцию групп. Это контроллеры, да их параметры вырастают в длинный список среди которых трудно искать нужные - вот там бы группировка помогла.
roman wrote:
Как насчёт переименовать "Контроллеры" в "Устройства"?
"контроллер" можно переименовать в "виртуальный контроллер" или в "процесс". А лучше так и оставить, привыкли уж давно и суть концепции лучше выражает.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 03. 08. 2009 [15:04]
|
|
Aleksey
Aleksey Popkov
Contributor
registered since: 31.07.2008
Posts: 326
|
almaz wrote:
"контроллер" можно переименовать в "виртуальный контроллер" или в "процесс". А лучше так и оставить, привыкли уж давно и суть концепции лучше выражает.
Согласен.
|
|
Written on: 03. 08. 2009 [15:15]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
almaz wrote:
roman wrote:
Думаю в этом месяце доберусь и сделаю на основе Vision такой редактор.
Ура! Да свершится! А концепция языка графического программирования будет? Все-таки что будет браться за основу? FBD, VI или UML?
Абстрактный блочный язык. А уже от сущности блока получится то что нужно. Это будет просто оболочка над BlockCalc, помогающая формировать модели и другие алгоритмы визуально.
almaz wrote:
Листы (страницы) - это контроллеры блочного вычислителя?
На листы накидываются три составляющие: переменные (с логического уровня, параметры блочного вычислителя), функции (блоки блочного вычислителя), связи.
Где-то так
almaz wrote:
roman wrote:
Смотря где. Для проекта не жёстко, а для библиотек жёстко. Для библиотек не вижу особого смысла делать иерархически, да и сложнее это.
А названия библиотек и так неплохо выполняют функцию групп. Это контроллеры, да их параметры вырастают в длинный список среди которых трудно искать нужные - вот там бы группировка помогла.
А это вряд-ли. Структура там должна быть фиксированная.
almaz wrote:
roman wrote:
Как насчёт переименовать "Контроллеры" в "Устройства"?
"контроллер" можно переименовать в "виртуальный контроллер" или в "процесс". А лучше так и оставить, привыкли уж давно и суть концепции лучше выражает.
OK
Learn, learn and learn better than work, work and work.
|
|
Written on: 03. 08. 2009 [15:47]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
Понятно.
Концепция графического языка программирования получается гениально простой.
Последний вопрос на эту тему:
Существует ли простая возможность реализации использования одного контроллера блочного вычислителя в роли функции блока другого контроллера блочного вычислителя?
То есть написание внутреннего алгоритма одного блока в виде блочной схемы.
P.S. Частично сам себе отвечу. Для этого случая использование переменных логического уровня во вложенной блочной схеме недопустимо (только параметры этого же контроллера блочного вычислителя).
[This article was edited 2 times, at last 03.08.2009 at 15:59.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 03. 08. 2009 [17:50]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
almaz wrote:
Последний вопрос на эту тему:
Существует ли простая возможность реализации использования одного контроллера блочного вычислителя в роли функции блока другого контроллера блочного вычислителя?
То есть написание внутреннего алгоритма одного блока в виде блочной схемы.
Не существует. Я думал об этом на момент проектирования. А именно, блок это не только функция, но и контекст данных который нужно где-то хранить. В том-же Siemens это называется функциональным блоком, каждый вызов которого ассоциируется с блоком данных. В случае с OpenSCADA его нужно ассоциировать с таблицей БД при вызове. Впрочем это не невозможно и может быть в будущем будет реализовано.
almaz wrote:
P.S. Частично сам себе отвечу. Для этого случая использование переменных логического уровня во вложенной блочной схеме недопустимо (только параметры этого же контроллера блочного вычислителя).
Ссылки нормально работают в локальной схеме между разными схемами и на другие источники данных.
Learn, learn and learn better than work, work and work.
|
|
Written on: 04. 08. 2009 [09:36]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
roman wrote:
Ссылки нормально работают в локальной схеме между разными схемами и на другие источники данных.
Это знаем. Просто мы используем логический уровень для хранения переменных блочных схем, а внешние ссылки для ввода-вывода данных в схему. Может быть это неправильно и лучше (быстродейственнее) хранить их в контроллере блочного вычислителя (ветка параметры), но работает.
roman wrote:
Думаю в этом месяце доберусь и сделаю на основе Vision такой редактор.
Тогда нам остается только принять активное участие в наполнении библиотеки блоков (есть наработки и будут), то есть сформировать графический язык программирования (элементную базу) и wiki-документацию . Куда эти блоки лучше размещать? В модуль "Специальные" или в библиотеку Ява-вычислителя? У нас сейчас наработки в яве, но в модуле "Специальные" функции должны выиграть по быстродействию.
P.S. По-моему модуль "Специальные" постепенно становится библиотекой элементов. То есть в модуле "Специальные" базовая библиотека функций, а в Ява-вычислителе - пользовательская библиотека функций.
Предложение!!! Склонировать модуль "Специальные" и назвать его "Библиотека функций". Ну и потом из модуля "Библиотека функций" удалить "Тесты системы", а из модуля "Специальные" удалить всю библиотеку функций
[This article was edited 3 times, at last 04.08.2009 at 10:08.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
