SMH4 сделать проброс

[alexsis_k]

Сразу прошу больно норами не пинать!
Реализована система: SMH4 в качестве контроллера верхнего уровня, к нему по ModBus подключены несколько СЛЭЙВОВ. Сам SMH4 через TCP включен в локалку и в качестве СЛЭЙВА отдает данные с SCADA на безе ПК.
Задача - иметь возможность делать SMH4 "прозрачным" для доступа к регистрам СЛЭЙВОВ. Иначе придется создавать Очень большую таблицу modbas переменных для каждого СЛЭЙВА, и то не факт, что заработает.

[Arsie]

Сообщение от alexsis_k

Очень большую таблицу modbas переменных для каждого СЛЭЙВА

Можете назвать более определённые числа, чем числа вида "большую" и "каждого"?

[Gel]

Сообщение от alexsis_k

Задача - иметь возможность делать SMH4 "прозрачным" для доступа к регистрам СЛЭЙВОВ.

А что это означает, что имеется в виду?

[alexsis_k]

Сообщение от Arsie

Можете назвать более определённые числа, чем числа вида "большую" и "каждого"?

Произвел подсчет. Переменных (регистров) отвечающих за конфигурацию СЛЭЙВА 677 шт, их у меня в данном проекте 4. Дополнительно есть регистры с рабочими и аварийными параметрами. Есть еще СЛЭЙВЫ но там количество регистров существенно меньше.


Добавлено через 2 минуты

Сообщение от Gel

А что это означает, что имеется в виду?

Иметь возможность обращаться к любому из СЛЭЙВОВ с компа минуя контроллер верхнего уровня. Ну допустим - переводим SMH4 в некий режим и уже по TCP ModBus слэйв доступен из локалки. Как то так, в порядке "фантазии".

[Gel]

Сообщение от alexsis_k

Иметь возможность обращаться к любому из СЛЭЙВОВ с компа минуя контроллер верхнего уровня. Ну допустим - переводим SMH4 в некий режим и уже по TCP ModBus слэйв доступен из локалки. Как то так, в порядке "фантазии".

Все равно не понятно. Можете картинку нарисовать и пояснить с указанием адресов, портов и т.п., типа такой, как ниже.

Картинку можно нарисовать здесь: https://draw.io/

[Gel]

Или, у вас примерно такая схема?

[alexsis_k]

Сообщение от Gel

Или, у вас примерно такая схема?

Ну если внимательно прочитать мой первый пост то получается, что картинка 2 как нельзя лучше описывает реализацию! Извините конечно но мне не понятно зачем "переливать из пустого в порожнее". Старался кратко описать реализацию и как мне кажется тут вопросов не могло возникнуть.

[Gel]

Сообщение от alexsis_k

Ну если внимательно прочитать мой первый пост то получается, что картинка 2 как нельзя лучше описывает реализацию! Извините конечно но мне не понятно зачем "переливать из пустого в порожнее". Старался кратко описать реализацию и как мне кажется тут вопросов не могло возникнуть.

Тогда, т.к. штатного способа организовать шлюз TCP-485 нет (реальный шлюз, а не его подобие через промежуточный опрос/хранение значений и ремаппинг регистров), то есть два варианта:

1) аппаратное решение -- купить готовый шлюз, подключить его по схеме 1 и в программе FBD для SMH4 перенастроить клиентов Modbus на этот шлюз;

2) программное решение -- найти программу-шлюз/агрегатор TCP-485 (или заказать ее разработку), установить на SMH4, в программе FBD для SMH4 перенастроить клиентов Modbus на этот шлюз.

[alexsis_k]

Сообщение от Gel

Тогда, т.к. штатного способа организовать шлюз TCP-485 нет (реальный шлюз, а не его подобие через промежуточный опрос/хранение значений и ремаппинг регистров), то есть два варианта:

1) аппаратное решение -- купить готовый шлюз, подключить его по схеме 1 и в программе FBD для SMH4 перенастроить клиентов Modbus на этот шлюз;

2) программное решение -- найти программу-шлюз/агрегатор TCP-485 (или заказать ее разработку), установить на SMH4, в программе FBD для SMH4 перенастроить клиентов Modbus на этот шлюз.

Я пытался про анализировать вариант 1 и ранее, но встает такой вопрос. Для связи со SCADA порт Ethernet настраивается как СЛЭЙВ, а для работы со СЛЭЙВАМИ он должен стать Мастером. Не понятно реализуемо это или нет.
Кроме того у это варианта есть ущербность. Если "ляжет" локалка то вся система остановится. В варианте когда СЛЭЙВы работают через ModBus становится не важным работа локалки, в худшем случаи SCADA не получит данных.

По варианту 2 у меня вообще понимания нет. Что за шлюз/агрегатор? Где его брать? Как его писать???

[младшой]

Сообщение от alexsis_k

Для связи со SCADA порт Ethernet настраивается как СЛЭЙВ, а для работы со СЛЭЙВАМИ он должен стать Мастером. Не понятно реализуемо это или нет.

Реализуемо.
SMH4 может использовать Ethernet для Modbus TCP будучи одновременно как мастером, так и слейвом.

[Gel]

Сообщение от alexsis_k

Я пытался про анализировать вариант 1 и ранее, но встает такой вопрос. Для связи со SCADA порт Ethernet настраивается как СЛЭЙВ, а для работы со СЛЭЙВАМИ он должен стать Мастером.

Прием подключения на порт 502 -- это всегда работа в режиме slave для MODBUS/TCP.

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

MODBUS/TCP мастер и слейв -- совершенно независимые вещи.

Сообщение от alexsis_k

Кроме того у это варианта есть ущербность. Если "ляжет" локалка то вся система остановится.

Думаю, вы ошибаетесь. Если свитч -- местный, то на подавляющее число проблем в сети ему все равно. Даже если выгорит порт подключения к общей сети, остальные могут и работать.

Или нужно пояснить, каких конкретно проблем вы опасаетесь. Чем это отличается от "ляжет 485 и вся система остановится" ?

Сообщение от alexsis_k

По варианту 2 у меня вообще понимания нет. Что за шлюз/агрегатор? Где его брать? Как его писать???

На первый взгляд, задача агрегации MODBUS кажется достаточно общей и типовой, что бы существовало какое-нибудь готовое решение. Если нужна разработка такой штуки -- можете написать в личку, могу сделать в качестве шабашки.

[Arsie]

Сообщение от Gel

На первый взгляд

Это только на первый взгляд.

Как будете параллелить опрос внешний и внутренний? Ясно, что внутренний будет через локалхост, но это однозначно будет ситуация двух мастеров для RS485. Разруливание этой неприятности автоматом тянет за собой ещё две. Которые за собой ещё тянут.


И это наименьшая из проблем. Именно поэтому я такой шлюз не написал сам. Так-то шлюзы есть готовые разной степени паршивости. Вот только задач они не решают, которые перед ними ставит именно PLC.

[Gel]

Сообщение от Arsie

Это только на первый взгляд.

Как будете параллелить опрос внешний и внутренний? Ясно, что внутренний будет через локалхост, но это однозначно будет ситуация двух мастеров для RS485.

Для RS485 это не будет ситуация двух мастеров, т.к. упорядочивание обращений к одной шине и так подразумевается.

Сообщение от Arsie

И это наименьшая из проблем. Именно поэтому я такой шлюз не написал сам.

Надо было просто изучить многопоточное программирование и разделение ресурсов и все бы получилось.

[Arsie]

Сообщение от Gel

Для RS485 это не будет ситуация двух мастеров, т.к. упорядочивание обращений к одной шине и так подразумевается.

С тайм-аутами что делать планируете? С джиттером доставки данных? С перегрузкой канала RS485?

[Gel]

Сообщение от Arsie

С тайм-аутами что делать планируете? С джиттером доставки данных? С перегрузкой канала RS485?

С таймаутом делать то же, что и обычно. Если какое-то устройтво зависает на 485, это и так уже проблема для всех остальных устройств (на этой конкретной шине 485). Не вижу тут что-то особенного.

С джиттером ничего делать не надо, зачем?

C перегрузкой канала тоже ничего делать не надо, это не проблема уровня шлюза. Какая разница, как шину перегружать, обращением к шлюзу или напрямую по 485?

[Arsie]

Сообщение от Gel

С таймаутом делать то же, что и обычно. Если какое-то устройтво зависает на 485

С тайм-аутами мастеров на эзернете.

Сообщение от Gel

С джиттером ничего делать не надо, зачем?

C перегрузкой канала тоже ничего делать не надо, это не проблема уровня шлюза. Какая разница, как шину перегружать, обращением к шлюзу или напрямую по 485?

Горизонт планирования понятен, вопросов больше не имею.

[Gel]

Сообщение от Arsie

С тайм-аутами мастеров на эзернете.

Арсений, опишите конкретную проблему, я же не телепат.

С вероятностью 99% полагаю, это будет вообще не проблема или проблема не уровня шлюза.

[Arsie]

Сообщение от Gel

Арсений, опишите конкретную проблему, я же не телепат.

С вероятностью 99% полагаю, это будет вообще не проблема или проблема не уровня шлюза.

К сожалению я не готов проводить полное исследование задачи "прозрачный модбас". Состоит она из трёх подзадач. Вы рассматриваете только одну из них, шлюзование. Две остальные игнорируете.

Я ж про шлюз писал уже: их есть в интернете, нет сложности скомпилить под контроллер. Возможно некоторые из них окажутся рабочими.

[Gel]

Сообщение от Arsie

Состоит она из трёх подзадач. Вы рассматриваете только одну из них, шлюзование. Две остальные игнорируете.

Да неправда, я на все ответил.

Если вы из модбас и палок пытаетесь сделать систему, критичную к миллисекундам, то естественно вас ждет провал.

[monstr696]

А если подключить так. Главное чтоб была возможность.