Modbus RTU & MODBUS ASCII по одной линии

Сообщение **Gleb Frolov** » 20 сен 2022, 21:00

Коллеги, всем добрый вечер ! Нужна помощь, есть работающее оборудование, часть работает по протоколу Modbus RTU , другая часть оборудования по Modbus ASCII.
Это оборудование интерфеймом соединено последовательно по одной линии. Через преобразователь интерфейсов rs485 в rs232 и заведен в древний контроллер контроллер Octagon ( не суть важно) . В общем пытался я подлючаться через nport 5230 по rs 485 . И через opc server разложить эти два сигнала, но пока результатов это не дало. Есть какие ещё варианты? В общем задача и состоит в том , чтобы как то разделить два протокола идущие по одному интерфейсу и завести потом в свою scada. Через mgate( при выборе нужного протокола RTU или ASCII) эти устройства видны .

Сообщение **Serex** » 21 сен 2022, 11:36

А в чем вопрос то? Сами же написали разделить на две линии - то все работает. Или лишнего порта жалко?

Сообщение **Gleb Frolov** » 21 сен 2022, 13:15

Линия сейчас одна, разделить физически устройства с разным протоколами нету возможности, так как устройства находятся в труднодоступных местах. Поэтому и думаю как можно их разделить программно.

Сообщение **Valerich** » 21 сен 2022, 13:43

Gleb Frolov писал(а): ↑20 сен 2022, 21:00 В общем пытался я подлючаться через nport 5230 по rs 485 . И через opc server разложить эти два сигнала, но пока результатов это не дало

Хоть какой-то результат есть?
Мастер остается тот-же(контроллер)?
По-отдельности RTU/ASCII пробовали? Если работает по-отдельности, то поставьте 2 преобразователя.

Сообщение **rwg** » 21 сен 2022, 14:07

Gleb Frolov писал(а): ↑21 сен 2022, 13:15 как можно их разделить программно

Написать свой OPC-сервер, которая будет опрашивать оба устройства. Не знаю, как сейчас, а лет 10-15 назад отдельные программисты на Дельфи брались и легко решали эту задачу.
[/quote]

Valerich писал(а): ↑21 сен 2022, 13:43 поставьте 2 преобразователя

Если два преобразователя начнут одновременно по общей линии опрашивать свои устройства, может произойти всё, что угодно. Только или по очереди, или через общий преобразователь. А для этого опять нужен программист.

Сообщение **Serex** » 21 сен 2022, 14:13

Выходит, что некий контроллер опрашивает либо в Rtu, либо ASCII и является мастером. В этом мастере хитрый драйвер, который чередует запросы в разных форматах.

Остается только программно повторить данный драйвер.
Готовые решения мне не известны.

Сообщение **Gleb Frolov** » 21 сен 2022, 14:45

/quote]
Хоть какой-то результат есть?
Мастер остается тот-же(контроллер)?
По-отдельности RTU/ASCII пробовали? Если работает по-отдельности, то поставьте 2 преобразователя.
[/quote]

Ops сервер ( kep server) после добавления двух устройств с разными протоколами, выдает ошибку (см фото) . В общем, что Com порт не может обработать протоколы RTU и ASCII одновременно. Через mgate MB3480 опрашиал по отдельности сначала в режиме RTU , потом в режиме ASCII , устройства находятся. Мне кажется с двумя преобразователями тоже вылетит какая нибудь ошибка.

Отправлено спустя 3 минуты 4 секунды:

Serex писал(а): ↑21 сен 2022, 14:13 Выходит, что некий контроллер опрашивает либо в Rtu, либо ASCII и является мастером. В этом мастере хитрый драйвер, который чередует запросы в разных форматах.

Остается только программно повторить данный драйвер.
Готовые решения мне не известны.

Да все верно, на каком именно новом железе это можно реализовать это вопрос.

Сообщение **rwg** » 21 сен 2022, 15:04

Gleb Frolov писал(а): ↑21 сен 2022, 14:48 В общем, что Com порт не может обработать протоколы RTU и ASCII одновременно

СОМ- порту безразлично, по какому протоколу вы работаете. Одновременно (точнее поочерёдно) их не может обработать OPC-сервер. Общепринято, что одна линия - один протокол, лично я не знаю такого сервера, который позволяет менять протокол во время работы. И никто не гарантирует, что датчики с разными протоколами на одной линии смогут работать одновременно, не будут мешать друг другу. Вам скорее всего придётся работать на свои страх и риск с нестандартным программным обеспечением и с риском конфликтов между датчиками.

Сообщение **Valerich** » 22 сен 2022, 06:38

Так и не ответили: мастером останется старый контроллер а OPC будет слушать или контроллер уберется и мастером станет OPC сервер?

Сообщение **M3f** » 22 сен 2022, 09:46

Gleb Frolov писал(а): ↑21 сен 2022, 14:48
Serex писал(а): ↑21 сен 2022, 14:13 Выходит, что некий контроллер опрашивает либо в Rtu, либо ASCII и является мастером. В этом мастере хитрый драйвер, который чередует запросы в разных форматах.

Остается только программно повторить данный драйвер.
Готовые решения мне не известны.
Да все верно, на каком именно новом железе это можно реализовать это вопрос.

Я реализовывал похожую задачу на Siemens-e (S7-315-2PN/DP + CP341, но можно и на более дешевой серии, например S7-1200 или вообще на другом PLC который поддерживает "free protocol"). У меня было на одной линии несколько устройств с Modbus RTU и ряд задвижек со своим собственным протоколом (на базе Modbus ASCII).
Для реализации необходимо хорошее понимание самих протоколов и PLC на котором будет реализация, так как структуру и очередность запросов необходимо писать самому.

Сообщение **Prosto_chel** » 22 сен 2022, 10:11

Можно использовать шлюзы типа Anybus AB7010.
Выбираешь режим "нестандартный протокол" и вручную прописываешь команды: для одних узлов Modbus ASCII, для других - RTU. Все полученные данные будут лежать в регистрах памяти шлюза и будут доступны по протоколу Modbus RTU (шлюз с этой стороны будет стандартным Modbus RTU Slave). Единственное, потом надо будет разбирать - какие данные в ASCII, а какие нет

Сообщение **Ryzhij** » 22 сен 2022, 10:34

Gleb Frolov писал(а): ↑21 сен 2022, 14:48 Да все верно, на каком именно новом железе это можно реализовать это вопрос.

Всё зависит от задачи.
Если точек опроса немного, то в качестве шлюза с общим количеством самых разношерстных собираемых параметров до 64, можно использовать и ОВЕН МСД200. Он может собирать данные даже по трём протоколам (RTU, ASCII и OWEN), но с одним и тем же битрейтом. Эти данные можно забирать с модуля по другому порту по RTU пакетами (от 1 до 40 параметров за раз) с информацией о состоянии связи с конечным прибором, о формате данных и прочем.