Вопрос о ModBus
| 1 | 2 | 3 | Дальше | В конец
| Автор |
Сообщение |
|
Сообщение создано: 10. 12. 2008 [21:49]
|
|
andrey-sw
Андрей Сычев
Создатель темы
Зарегистрирован(а) с: 10.12.2008
Сообщения: 32
|
Есть весовой контроллер, в котором хранятся архивы взвешиваний. Всё это богатство доступно по протоколу ModBus. Архив организован в блоки регистров.
Адрес Значение
8301+(N-1)*23 Переменная1
8302+(N-1)*23 Переменная1
8303+(N-1)*23 Переменная1
8304+(N-1)*23 Переменная1
8305+(N-1)*23 Переменная1
...
где N номер записи
Как можно организовать чтение данного архива?
Или как можно читать регистры без жесткой привязки к адресу, например указывая некоторую переменную в качестве адреса регистра, или может быть есть возможность формировать произвольные запросы по протоколу ModBus и "вручную" разбирать ответы?
Попутно еще вопрос.
Можно ли опрашивать контроллер не периодически, а например по запросу оператора, или по какому нибудь событию?
[Сообщение редактировалось 4 раз(а), в последний раз 10.12.2008 в 22:09.]
|
|
Сообщение создано: 11. 12. 2008 [08:26]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Можно ли опрашивать контроллер не периодически, а например по запросу оператора, или по какому нибудь событию?
Помоиму можно включить требуемый контроллер по какому-то событию. Правда я так еще не делал. )))
[Сообщение редактировалось 1 раз(а), в последний раз 11.12.2008 в 08:31.]
|
|
Сообщение создано: 11. 12. 2008 [09:44]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
andrey-sw wrote:
Есть весовой контроллер, в котором хранятся архивы взвешиваний. Всё это богатство доступно по протоколу ModBus. Архив организован в блоки регистров.
Адрес Значение
8301+(N-1)*23 Переменная1
8302+(N-1)*23 Переменная1
8303+(N-1)*23 Переменная1
8304+(N-1)*23 Переменная1
8305+(N-1)*23 Переменная1
...
где N номер записи
Как можно организовать чтение данного архива?
Это нестандартное использование протокола ModBus. Модуль DAQ.ModBus реализует только стандартные механизмы доступа, поэтому и называется так, а не аля ТипНестандартногоВесовогоКонтроллера.
andrey-sw wrote:
Или как можно читать регистры без жесткой привязки к адресу, например указывая некоторую переменную в качестве адреса регистра, или может быть есть возможность формировать произвольные запросы по протоколу ModBus и "вручную" разбирать ответы?
Такой возможности нет. Хотя добавить функцию пользовательского API для выполнения запросов произвольных регистров достаточно просто. Но это будет далеко не оптимально. Сейчас модуль собирает указанные регистры в блоки и запрашивает их одним запросом. Кроме того, это безсистемно и не наглядно. Особенно если учесть тот факт, что описанные Вами данные нужно не просто получать, а нормально положить в собственный архив.
andrey-sw wrote:
Попутно еще вопрос.
Можно ли опрашивать контроллер не периодически, а например по запросу оператора, или по какому нибудь событию?
Можно и называется этот механизм "Синхронный". Но это определяет совокупная природа контроллера, протокола и интерфейса. Для высоколатентных интерфейсов, требующих оптимизации и группировки запросов используется "Асинхронный механизм" (DAQ.ModBus). Для низко-латентных используется "Синхронный" (DAQ.System).
Подобную задачу с контроллерами, расширяющими протокол обмена ModBus нестандартными механизмами я уже встречал. Решать их можно двумя путями. Первый - делать модуль DAQ.ModBus самого модульным. Второй, более правильный, писать отдельный модуль на данный тип контроллера и в нём учитывать особенности расширения протокола ModBus. В свете подвижек по вынесению протокольной части ModBus на уровень транспортных протоколов OpenSCADA это может значительно упроститься и исключит необходимость дубляжа этого кода в каждом модуле сбора данных.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 12. 2008 [13:31]
|
|
andrey-sw
Андрей Сычев
Создатель темы
Зарегистрирован(а) с: 10.12.2008
Сообщения: 32
|
roman wrote:
Такой возможности нет. Хотя добавить функцию пользовательского API для выполнения запросов произвольных регистров достаточно просто.
Имеется в виду подключение своих функций через библиотеку наподобии FLibSYS или FLibMatch
roman wrote:
Можно и называется этот механизм "Синхронный". Но это определяет совокупная природа контроллера, протокола и интерфейса. Для высоколатентных интерфейсов, требующих оптимизации и группировки запросов используется "Асинхронный механизм" (DAQ.ModBus). Для низко-латентных используется "Синхронный" (DAQ.System).
Не совсем понял как организовать "Синхронный" механизм.
Например есть несколько контроллеров и десятки додулей ввода-вывода. По некоторому рецепту выдается задание контроллерам (записывается несколько регистров) проверяется состояние системы вцелом (прашиваются МДВВ) и процес запускается на выполнение и контролируется путем опроса 1рег в котроллерах и рег МДВВ. Причем контроль выполнения нужно вести с максимальной скоростью, тоесть из опроса нужно исключить конфигурационные регистры контроллеров.
Или второй пример, возвращаясь к архивам. Например архив будет организован след. образом:
Адрес Регистр
500 текущая запись архива
501 Var1 тек записи
502 Var2 тек записи
503 Var3 тек записи
504 Var4 тек записи
...
как в таком случае организовать чтение архива.
Если использовать Асинхронный механизм, то в силу непредсказуемости порядка опроса и записи регистров, после записи в 500 регистр номера нужной записи архива нельзя с уверенностью сказать что последуючие регистры уже прочитаны и содержат нужные данные. По идее в данном случае нужно записать номер записи, прочитать его и убедится что он изменился, затем 1 раз прочитать остальные регистры.
P.S.
Интересуюсь этим не из праздного любопытства, а работаю над довольно серьёзным проектом. Раньше подобные вещи реализовывал путем программирования на C++, но очень много времени отнимает создание визуализаций и организация архивов. Сейчас пытаюсь реализовать данную задачу используя OpenScada. Предпосылки к удачному исходу вроде бы есть, но и есть некоторые специфические трудности присущие данным задачам. Если все получится то у вас пополнится список успешных применений OpenScada на производстве.
|
|
Сообщение создано: 11. 12. 2008 [20:18]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
andrey-sw wrote:
Имеется в виду подключение своих функций через библиотеку наподобии FLibSYS или FLibMatch
Не обязательно. Функции пользовательского API могут добавляться и прямо в модуль DAQ. Делая их прозрачно контекстно-зависимыми.
andrey-sw wrote:
roman wrote:
Можно и называется этот механизм "Синхронный". Но это определяет совокупная природа контроллера, протокола и интерфейса. Для высоколатентных интерфейсов, требующих оптимизации и группировки запросов используется "Асинхронный механизм" (DAQ.ModBus). Для низко-латентных используется "Синхронный" (DAQ.System).
Не совсем понял как организовать "Синхронный" механизм.
Никак. Модуль или его поддерживает или нет. DAQ.ModBus его не поддерживает ибо там он не нужен.
andrey-sw wrote:
Например есть несколько контроллеров и десятки додулей ввода-вывода. По некоторому рецепту выдается задание контроллерам (записывается несколько регистров) проверяется состояние системы вцелом (прашиваются МДВВ) и процес запускается на выполнение и контролируется путем опроса 1рег в котроллерах и рег МДВВ. Причем контроль выполнения нужно вести с максимальной скоростью, тоесть из опроса нужно исключить конфигурационные регистры контроллеров.
Для этой задачи достаточно и DAQ.ModBus в его настоящем виде.
andrey-sw wrote:
Или второй пример, возвращаясь к архивам. Например архив будет организован след. образом:
Адрес Регистр
500 текущая запись архива
501 Var1 тек записи
502 Var2 тек записи
503 Var3 тек записи
504 Var4 тек записи
...
как в таком случае организовать чтение архива.
Писать новый модуль, ибо в стандартном ModBus про архивы ничего не сказано. А производители железок архивы накладывают на ModBus как им взбрендит.
andrey-sw wrote:
Если использовать Асинхронный механизм, то в силу непредсказуемости порядка опроса и записи регистров, после записи в 500 регистр номера нужной записи архива нельзя с уверенностью сказать что последуючие регистры уже прочитаны и содержат нужные данные. По идее в данном случае нужно записать номер записи, прочитать его и убедится что он изменился, затем 1 раз прочитать остальные регистры.
Вот эту функцию и должен реализовывать новый модуль, индивидуальный для данного типа контроллера. При этом он будет полученный архив прозрачно вычитывать и укладывать в архив OpenSCADA, т.е. работать в так называемом пакетном режиме. Причём можно предусмотреть и функцию вычитки архива по команде, через функцию пользовательского API. Стандарный модуль DAQ.ModBus работает только в режиме реального времени.
andrey-sw wrote:
P.S.
Интересуюсь этим не из праздного любопытства, а работаю над довольно серьёзным проектом. Раньше подобные вещи реализовывал путем программирования на C++, но очень много времени отнимает создание визуализаций и организация архивов. Сейчас пытаюсь реализовать данную задачу используя OpenScada. Предпосылки к удачному исходу вроде бы есть, но и есть некоторые специфические трудности присущие данным задачам. Если все получится то у вас пополнится список успешных применений OpenScada на производстве.
Это хорошо, конечно. Но задача с архивом не решается нормально в рамках стандартного модуля DAQ.ModBus в виду не стандартности использования ModBus протокола производителем железки. У меня самого есть спецификация протокола на одну такую. Планируется решение этой проблемы путём создания специализированного под эту железку модуля или расширение DAQ.ModBus до собственной модульности учитывающей подобный разброд и шатание. Сейчас ведуться подготовительные работы по переносу протокольной части кода ModBus в подсистему "Транспортные протоколы" OpenSCADA. Это добавит возможность работы OpenSCADA как slave сетей ModBus/RTU/ASCII и ModBus/TCP, а также позволит достаточно просто создавать модули сбора данных у железа с подобными особенностями. Но до релиза 0.6.3 активных действий лично я там делать не буду. Один человек обещал этим заняться. Если интересно - присоединяйтесь.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 12. 2008 [23:47]
|
|
andrey-sw
Андрей Сычев
Создатель темы
Зарегистрирован(а) с: 10.12.2008
Сообщения: 32
|
Хорошо ситуация немного прояснилась.
И еще один вопрос. Есть ли возможность выполнять команды Shell-а,
тоесть едея следующая, приостановить опрос, запустить внешнее приложение, которое прочитает архив и положит его в базу, а затем востановить опрос.
|
|
Сообщение создано: 12. 12. 2008 [09:38]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
andrey-sw wrote:
Хорошо ситуация немного прояснилась.
И еще один вопрос. Есть ли возможность выполнять команды Shell-а,
тоесть идея следующая, приостановить опрос, запустить внешнее приложение, которое прочитает архив и положит его в базу, а затем востановить опрос.
Где это нужно он запускает утилиты, например для синтеза речи и проигрывания звука. Но читать архивы неизвестного происхождения!? Для работы с собственной подсистемой архивов все механизмы есть.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 12. 12. 2008 [11:49]
|
|
andrey-sw
Андрей Сычев
Создатель темы
Зарегистрирован(а) с: 10.12.2008
Сообщения: 32
|
roman wrote:
andrey-sw wrote:
Хорошо ситуация немного прояснилась.
И еще один вопрос. Есть ли возможность выполнять команды Shell-а,
тоесть идея следующая, приостановить опрос, запустить внешнее приложение, которое прочитает архив и положит его в базу, а затем востановить опрос.
Где это нужно он запускает утилиты, например для синтеза речи и проигрывания звука. Но читать архивы неизвестного происхождения!? Для работы с собственной подсистемой архивов все механизмы есть.
Вы не совсем правильно поняли вопрос. Речь идет об архивах контролера, доступ к которым осуществляется используя нестандартное применение ModBus. Организовать такой доступ используя штатный модуль без его(или другого модуля) модификации невозможно(см. предыдущие сообщения), вот я и предлагаю отдать эту нестандартную задачу внешнему приложению, которое запускалосьбы из Системы OpenScada по требованию оператора. Конечно можно научить оператора делать этот опрос штатными средствами ОС, но хотелосьбы всетаки все делать из интерфейса OpenScada.
Тоесть нужна лиш функция для выполнения команды шела с определенными параметрами, ну и функция для управления опросом контролера в модуле ModBus точнее програмное управление состоянием параметра контролера в модуле ModBus (Вкл\Выкл). Соответственно вызывать эти функции нужно будет например по нажатию кнопки из Пользователеского интерфейса
|
|
Сообщение создано: 12. 12. 2008 [22:37]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
andrey-sw wrote:
Вы не совсем правильно поняли вопрос. Речь идет об архивах контролера, доступ к которым осуществляется используя нестандартное применение ModBus. Организовать такой доступ используя штатный модуль без его(или другого модуля) модификации невозможно(см. предыдущие сообщения), вот я и предлагаю отдать эту нестандартную задачу внешнему приложению, которое запускалосьбы из Системы OpenScada по требованию оператора. Конечно можно научить оператора делать этот опрос штатными средствами ОС, но хотелосьбы всетаки все делать из интерфейса OpenScada.
Такой функции нет. Её тоже нужно делать как функцию пользовательского API.
andrey-sw wrote:
Тоесть нужна лиш функция для выполнения команды шела с определенными параметрами,
И что эта функция будет делать?
andrey-sw wrote:
ну и функция для управления опросом контролера в модуле ModBus точнее програмное управление состоянием параметра контролера в модуле ModBus (Вкл\Выкл). Соответственно вызывать эти функции нужно будет например по нажатию кнопки из Пользователеского интерфейса
А это тогда зачем?
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 13. 12. 2008 [15:59]
|
|
andrey-sw
Андрей Сычев
Создатель темы
Зарегистрирован(а) с: 10.12.2008
Сообщения: 32
|
roman wrote:
andrey-sw wrote:
Вы не совсем правильно поняли вопрос. Речь идет об архивах контролера, доступ к которым осуществляется используя нестандартное применение ModBus. Организовать такой доступ используя штатный модуль без его(или другого модуля) модификации невозможно(см. предыдущие сообщения), вот я и предлагаю отдать эту нестандартную задачу внешнему приложению, которое запускалосьбы из Системы OpenScada по требованию оператора. Конечно можно научить оператора делать этот опрос штатными средствами ОС, но хотелосьбы всетаки все делать из интерфейса OpenScada.
Такой функции нет. Её тоже нужно делать как функцию пользовательского API.
andrey-sw wrote:
Тоесть нужна лиш функция для выполнения команды шела с определенными параметрами,
И что эта функция будет делать?
Возможно мы несколько расходимся в терминологии, но я имел ввиду следующее:
При нажатии кнопки в визуализации должен выполнится скрипт например на JavaLike а из которого уже выполняется функция что то типа ShelExec('cmd','params')
roman wrote:
andrey-sw wrote:
ну и функция для управления опросом контролера в модуле ModBus точнее програмное управление состоянием параметра контролера в модуле ModBus (Вкл\Выкл). Соответственно вызывать эти функции нужно будет например по нажатию кнопки из Пользователеского интерфейса
А это тогда зачем?
Если опрос ведется по ModBusTCP то в этом нет необходимости, а вот если используя последовательный порт, то для работы с контроллером из другого приложения (запущенного из функции описанной выше) необходимо предварительно освободить порт, или я не прав?
Ну да ладно раз такой финкции нет то и в этом надобность отпадает.
Буду использовать то что есть, а там видно будет,
|
| 1 | 2 | 3 | Дальше | В конец
|
|
