Сети‎ > ‎

Modbus проектирование (рус)

6.5. Рекомендации к проектированию сетей MODBUS RTU / ASCII и MODBUS TCP.

Основными преимуществами сетей MODBUS перед другими сетями является их простота и бюджетность решения. Как было отмечено во 2-м разделе, нередко выбор конкретной сети диктуется имеющимися ограничениями со стороны выбранной платформы. Если выбранные средства имеют интегрированные каналы с поддержкой MODBUS, то при необходимости построения сетевых структур есть смысл в их использовании. Только если данное решение принципиально не подходит по ряду критериев, необходимо менять конфигурацию оборудования а иногда и сами программно-технические средства. В данном подразделе рассмотрим общие подходы к проектированию сетей MODBUS в типичных ситуациях, общая же последовательность разработки интегрированных автоматизированных систем приведена в разделе 15

6.5.1. Последовательность разработки сетей MODBUS RTU / ASCII

В общем случае проектирование сетей MODBUS RTU можно проводить по алгоритму, приведенному на рис.6.36 (для MODBUS ASCII аналогично). Учитывая функционирования протокола прикладного уровня по модели Климент-Сервер обмена сообщениями, в блоке 1 необходимо определить узлы, которые должны инициировать обмен. Среди типов программно-технических средств, указанных в разделе 1 данного пособия, типичными инициаторами обмена могут быть:

- Средства человеко машинного интерфейса (ЧМИ), к которым относятся ОП и компьютеры со SCADA/HMI;

- Контроллеры, которым необходимо доступаться к другим контролерам  или к периферийным средствам;

- Программаторы или конфигураторы.

Напомним, что средства ЧМИ обмениваются данными с контроллерами, периферийными или другими средствами ЧМИ. Для отображения изменяющихся данных процесса, средства ЧМИ опрашивают их значения с определенной периодичностью и только в том случае, когда отображаемая страница является активной. Такое поведение является логичной, поскольку экономятся временные ресурсы сети. Однако некоторые средства ЧМИ дают возможность постоянного опроса данных. В частности это характерно для операций ведения архивов а также для задач тревог и аварий. Запись данных процесса с ЧМИ производится как правило только при их изменении. Поэтому логично, что средства ЧМИ в сети должны быть Клиентами. Исключением могут быть ситуации, когда в сети должно быть несколько средств ЧМИ, или когда есть необходимость в передаче срочных сообщений на терминал. Эти ситуации рассмотрены ниже.

При необходимости обмена данными контроллера с другим контроллером, или с периферийными средствами, он должен инициировать обмен, т.е. быть Клиентом.

Программаторы и конфигуратор тоже должны быть Клиентами. В связи с тем, что подключение их к сети производится только при необходимости, и при условии отсутствия требований к одновременному функционирования сети вместе с изменением конфигурации/программы сетевых узлов, можно считать, что программатор не входит в структуру сети. В противном случае, необходимо выделять отдельный канал, т.е. выделять отдельную сеть для устройств, которые необходимо программировать, если такое возможно (блок 14).

В любом случае, количество клиентских узлов не может быть больше одного, так-как клиентский прикладной процесс в MODBUS RTU может находиться только на Веду щем узле. Если количество Клиентов (блок 1) все же больше одного можно попробовать перенести клиентские запросы узлов на один узел с правами Ведущего (блок 4). Ниже рассмотрены несколько примеров такого переноса. Если перенос не удается по определенным причинам, необходимо на узлах выделить отдельные каналы, то есть вместо одной сети создать несколько сетей, если такое возможно (блоки 14 и 16), или изменить техничесоке обеспечение узлов (блок 15).

Если Клиент только один, его прикладной Процесс будет выполняться на узле с правами Ведущего шины (блок 3). После всех проведенных выше проверок, необходимо согласовать физические интерфейсы (блок 5) и при необходимости использовать адаптеры преобразователи. При больших длинах линий необходимо подобрать репитер, после чего определиться с конечной структурой, битовыми скоростями и проверить соответствие физических характеристик требованиям MODBUS RTU.

При наличии временных коммуникационных характеристик для портов всех средств, участвующих в обмене, желательно рассчитать ориентировочное время обмена, расчет которого показан в примере 6.4. Если время обмена удовлетворяет, то сеть подходит для решения поставленных задач и можно переходить к разработке документов рабочего проекта.

 6.5.2. Перенос клиентских запросов в сетях MODBUS RTU / ASCII

Если при проектировании сети MODBUS RTU оказалось несколько прикладных Процессов Клиентов, можно попытаться их перенести на один узел.

На рис.6.37 показан пример решения задачи, в которой необходимо соединить в сеть четыре ПЛК (PLC1-PLC4), для обмена данными с определенной периодичностью. Рассмотрим, какой из PLC должен быть Клиентом, а следовательно и Ведущим MODBUS RTU.

Учитывая, что обмен данными должен быть периодическим, то каждый из ПЛК для информационных потоков может быть как инициатором обмена, т.е. Клиентом, так и Сервером. Можно ли ыделить единственный Клиентский узел? PLC1 - не может быть единственным клиентским узлом, поскольку присутствует информационная связь между PLC3 и PLC4. PLC2 тоже не может, из-за связей PLC3-PLC1 и PLC3-PLC4. Для PLC3, так как и для PLC4, остается недостижимыми связь PLC1-PLC2. Для PLC4 кроме того не может быть Клиентом из-за связи PLC3-PLC1. Таким образом явно выделяются как минимум два Клиента: PLC1 и PLC3.

 

Решение данной задачи может быть перенос клиентских запросов на один из узлов, например PLC3. Прямые клиентские запросы остаются: PLC3 записывает значения перем3_1 в перем1_1, считывает значение из перем4 в перем3_2. Для реализации связи между перем2 и перем1_2, необходимо чтобы PLC3 считывал эти значения с PLC2, после чего записывал их в PLC1. Как правило для этого выделяется дополнительный буфер, в примере это перем3_3.

Выбор узла с клиентским прикладным Процессом, а следовательно Ведущего, может проводиться по различным критериям: способность коммуникационных каналов работать в режиме MODBUS RTU Ведущего или Ведомого, мощность коммуникационных каналов (производительность запросив, обрабатываемых ПЛК), мощность процессора, удобство программирования или конфигурирования, количество прямых клиентских запросов, удобство настройки и т.д. В нашем случае мы остановились на PLC3, что обусловлено уменьшением количества косвенных клиентских запросов.

Рассмотрим следующий случай. При необходимости подключения к единой сети MODBUS RTU нескольких средств человеко-машинного интерфейса, которые, как мы отметили, должны формировать клиентские запросы, возникает необходимость в нескольких Ведущих. На рис.6.38 продемонстрирован пример, в котором необходимо подключить две операторские панели к одному ПЛК как для отображения так и для управления. Ни одна из операторских панелей не может взять на себя эксклюзивные права Клиента, поскольку другая операторская панель не сможет получать данные. Если операторские панели поддерживают MODBUS RTU в режиме Ведомого, а ПЛК в режиме Ведущего, то решение этой задачи может быть как на рис.6.38 (справа). Для этого в операторских панелях должна быть выделена область памяти (на рис.6.38 перем2 и перем3), с которой будет обмениваться ПЛК, генерируя запросы на чтение и запись регистров/битов. Отображение и изменение значений перем1 с операторских панелей будет проходить через эти выделенные области.

Хотя в рассматриваемом примере используются операторские панели, аналогично решается ситуация, когда в качестве средств человеко-машинного интерфейса выступают ПК со SCADA, или комбинация ОП и SCADA. Для SCADA в этом случае необходимо наличие драйверов MODBUS RTU в режиме Ведомого.

В поставленой задаче перенос клиентских запросов на одно из средств человеко-машинного интерфейса возможен, однако далеко не всегда, поскольку в этом случае необходимо реализовать переприсвоение переменных с различными источниками данных. Кроме того, средства ЧМИ в большинстве случаев не могут обеспечить детерминированное время доставки данных.

6.5.3. Последовательность разработки сетей MODBUS TCP / IP

 В отличие от MODBUS RTU/ASCII в MODBUS TCP/IP, как правило базируется на Ethernet, нет проблем с наличием клиентских запросов только на одном узле. Прикладной Процесс на узле может быть одновременно как Клиентом так и Сервером. При разработке сети учитывают физические особенности средств Ethernet (см. раздел 10). Таким образом в общей последовательности проекта для построения сети можно выделить следующее:

1. Определение клиентских узлов.

2. Определение поддержки потенциальными клиентскими узлами режима MODBUS Клиента, а серверными - режима MODBUS Сервера.

3. Перенос клиентских или серверных запросов на другие узлы при необходимости.

4. Расчет ориентировочного времени транзакции между узлами Клиента и Сервера.

5. Разработка сетевых схем на базе Ethernet.

Расчет ориентированного времени транзакции для MODBUS TCP/IP базируется на тех же принципах что и MODBUS RTU/ASCII. Однако вместо времени, затрачиваемого на передачу кадра, необходимо учесть время реакции коммуникационных средств Etherent (концентраторов, коммутаторов, мостов, шлюзов и т.д.).

 

Modbus протокол (рус)-> Modbus RTU/ASCII (рус) -> Modbus/TCP(рус)-> Modbus проектирование

 

Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com

Обсудить на форуме   

Comments