Настройка модема Robustel m1000 pro v2

[shyub]

Сеть построена на модемах Robustel m1000 pro v2 (1 сервер и 13 клиентов). Используется протокол Modbus RTU.
Как настроить модем, чтобы при получении запроса от клиента сервер мог передать ему команду? Возможно ли это?

[Jackson]

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

Кому "ему" ? Модему?

Отправлено спустя 4 минуты 19 секунд:
Во-1-х, ModBUS-TCP сервер команд передавать не может. Команды передаёт клиент. Но одно и то же устройство в ModBUS-TCP может быть и сервером, и клиентом, если оно это умеет. Но у Вас RTU, а в RTU слейв не может вдруг стать мастером. Во-2-х, насколько понимаю, модем даёт прозрачный канал, это значит что модем трафик просто пропускает через себя, как команду себе он вряд ли его воспримет (иначе это не прозрачный канал).

Вы задачу опишите: что надо скомандовать, кому и зачем. А то ничего не понятно.

[shyub]

Необходимо автоматизировать систему водоснабжения сельских водонапорных башень. Есть насосная станция, которая отбирает воду из центрального водовода, осуществляет хлорирование и по мере необходимости включает насосы для заполнения соответствующей водонапорной башни. Некоторые башни питаются водой не от насосной станции, а от ближайшей башни, которая имеет свой насос. Самая ближайшая башня удалена от насосной на 9 км. Рельеф местности не обеспечивает прямую видимость, прокладка кабеля не рассматривается. Во всех населённых пунктах доступна CDMA и GSM связь.
Алгоритм работы примерно такой: сервер (насосная станция) периодически получает от клиентов (водонапорных башень) сообщения о уровне воды. В зависимости от этого при сеансе связи сервер должен включить/выключить соответствующий насос, открыть/закрыть соответствующую задвижку. При отсутствии сообщений от клиентов или подтверждений от сервера в течении, например 5-ти минут, насос выключается, задвижка закрывается.

В качестве модемов выбор сделан в пользу Robustel m1000 pro v2, т.к. он автоматически инициализируется и предоставляет канал Modbus RTU между клиентом и сервером. (Клиенты не обслуживаемые, т.е. там устанавливается промышленный контроллер Delta DVP20SX211R и модем). И вот тут начинаются проблемы, которые я пока не знаю, как решить.
Как я понял из документации Robustel m1000 pro v2 позволяет устанавливать связь только между двумя участниками сети (клиент-сервер), а надо, чтобы все клиенты могли общаться с сервером (передавать данные о уровне воды, состоянии задвижек и насосов, а так же получать от сервера соответствующие команды).

Существует программа RobustLink, которая грубо говоря выполняет роль облака. Однако заказчик эту идею сразу отклонил: "Я вам предоставлю модемы по количеству точек, 1 статический IP-адрес и решайте поставленную задачу как хотите".
Поддерживать связь с помощью SMS или CSD не подходит.

Может есть смысл на сервере установить обычный модем, написать самим сервер с 13-тью точками доступа, но тут тоже "непонятки". Неизвестно, в каком формате будут поступать на сервер данные от Robustel m1000 pro v2, а ставить клиентам простые модемы и самостоятельно формировать TCP протокол вряд ли получится на DVP20SX211R.

[Sokolov_Dmitry]

На ценральной станции поставить ПЛК с модбас ТСР , работа модбас мастером (плк должен поддерживать нужное количество TCP соединений)и роутер для связи вместо модема. Модемы на периферии настроить в "ТСР сервер, всегда на связи, шлюз ТСР/rtu".

[Jackson]

Так. Давайте теперь приводить в порядок исходные данные.
1. Было сказано, что протокол ModBUS RTU. Следовательно, нет никаких клиентов и серверов. Есть мастер и слейвы. Разница принципиальна. Определяйтесь.
2. В означенном Вами модеме RS-485. Стало быть Ваши модемы - это еще и шлюзы ModBUS RTU/TCP? Или у Вас всё-таки ModBUS RTU-over-TCP? Это не одно и то же что ModBUS-TCP. Определяйтесь.
3. GSM-модемы не могут установить соединения точка-точка друг с другом. Они коннектятся в интернет. Далее Ваш главный ПЛК, зная IP-адреса, может запрашивать конкретный модем. Но тут опять путаница протоколами. На одном это возможно, на другом нет.
4. Отказ от облака считаю глупым. Облако было бы сервером, а все устройства на всех станциях - клиентами. Откатанная схема, простая как швабра, и не надо платить за фиксированные IP (а платить за них в противном случае придется - столько же будет стОить оплата облака, если не дешевле).

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

А лучше подробную схему автоматизации нарисуйте, показав где какие сигналы. Это эффективнее разговоров.

В целом же, я считаю всю эту затею бредом сивой кобылы. Потому что GSM не является гарантированным каналом связи, никакое управление через него не является надежным. По определению. Чихнёт сеть - и Вы оставите без воды всех, или перельёте где-нибудь в лучшем случае, а потом заморозите. Каждая станция должна работать автономно по собственному алгоритму, и таким образом чтобы все станции вместе выполняли общую задачу. Я ещё не знаю как конкретно это в Вашем случае сделать (передо мной не стоит такой задачи - я в другой конторе тружусь), но точно знаю что это можно сделать и эти вещи делаются, в т.ч. и мной. А GSM вполне можно использовать для мониторинга всех 9 станций, и именно в облаке - тогда глядя в экран смартфона, сидя где угодно, можно будет легко понять, на какой конкретно станции проблема и куда высылать ремонтников. И те же ремонтники смогут всегда видеть общую картину, даже находясь в пути, онлайн, если сеть не чихнёт.
Как-то так.

[Looker]

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

Самое правильное, но возможно их технология не позволит это сделать, т.к.:

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

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

[shyub]

Я полностью согласен, что управлять такими вещами по GPRS огромная глупость, но оказался перед фактом.
Однако поставленную задачу надо решать.
У клиентов поставлю Robustel m1000 pro v2, на сервере модем типа "флешка", серверную часть буду писать сам или подберу какую-нибудь готовую SCADA. Смущает только модем Robustel m1000 pro v2 "с прозрачным портом", сможет ли он работать с сервером, ведь он (этот модем) расчитан на работу с таким же модемом для организации обмена между двумя устройствами (разумеется через GPRS по протоколу TCP/IP).

[Jackson]

Я полностью согласен, что управлять такими вещами по GPRS огромная глупость, но оказался перед фактом.
Однако поставленную задачу надо решать.

Вопрос: кому надо?

У клиентов поставлю Robustel m1000 pro v2, на сервере модем типа "флешка", серверную часть буду писать сам или подберу какую-нибудь готовую SCADA.

Вторая глупость. СКАДА точно не предназначена для управления. Тем более по таким каналам связи.

ведь он (этот модем) расчитан на работу с таким же модемом для организации обмена между двумя устройствами (разумеется через GPRS по протоколу TCP/IP).

Вы в этом уверены?

Отправлено спустя 1 минуту 29 секунд:

Самое правильное, но возможно их технология не позволит это сделать

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

[Looker]

Пока что я не вижу технических препятствий сделать так, как я предложил. Если такие трудности есть - перечислите их.

У него удаленные насосы. И правильно было сказано:

Потому что GSM не является гарантированным каналом связи, никакое управление через него не является надежным. По определению. Чихнёт сеть - и Вы оставите без воды всех, или перельёте где-нибудь в лучшем случае, а потом заморозите.

[Jackson]

У него удаленные насосы.

Это затрудняет. Но надо нарисовать всю тех.схему чтобы всё понять. Пока что я нерешаемых проблем не вижу.
На таких расстояниях даже резервированные проводные каналы связи порой отказывают, а тут - вообще GSM, на который и повлиять никак нельзя.
Если гипотетически предположить какое-то внешнее ЧП, смерч там прошёл или аномальный снегопад - рухнуть может и связь, и тогда до кучи люди и без воды останутся.

[+]

Казалось бы, какой нафиг на континентальной равнине смерч. А однако ж было

У меня там семья была. Когда связь легла - я наверное седых волос добавил пока до МЧС дозванивался. Потом был на месте: лес как косой скосило, как и часть домов, несколько человек погибло. А там районная больница, куда раненых везли в 1 очередь, и там вода была потому что водонапорка жила автономной жизнью и ни от чего не зависела кроме электричества. А вода ой как нужна была в тот момент.

Так что делайте, конечно, как хотите - Ваша задача, Вам и решать, shyub - но я бы делал как следует, а не как нибудь. Как-нибудь и само получится, и работать будет тоже как-нибудь.