- В этой теме 51 ответ, 6 участников, последнее обновление 7 месяцев, 2 недели назад сделано
.
-
Сообщения
-
За основу такого программного шлюза можно взять Коммуникатор, работающий без участия Сервера.
Можно хотябы в общих словах как именно?
Я написал тестовое консольное приложение, которое слушает TCP порт(условно 12000) и устанавливает TCP соединение с двумя другими TCP портами(12001 и 12002), каждый из которых прослушивают уже своя систем сбора данных соответственно. RapidScada сидит на «основном» порте(12001), другая система на «приоритетном»(12002). При опросе RapidScada, данные из порта 12001 передаются в порт 12000 и обратно. При опросе приоритетной системой (появлении данных от порта 12002), пакеты данных от порта 12001 игнорируются, пока тишина в порте 12002 не превысит установленный временной предел. Как прога для тестирования это работает. Надеюсь что понятно объяснил.
Вопрос как подобный алгоритм повторить с использованием исходного текста коммуникатора? Есть возможность манипулировать данными между линиями связи? Или имелось ввиду что-то другое? Может мой подход неверный. Конечно было бы идеально задействовать коммуникатор, поскольку там уже готово распаралеливание потоков и юзер интерфейс.
Нужно уточнить:
1. Используются какие-то конкретные протоколы обмена данными или это должно быть универсальное решение, не зависящее от протоколов?
2. Какая физическая архитектура для связи между устройствами и ПО (Ethernet, RS-485 и т.п.)?1. Думаю лучше делать универсальное решение, полностью прозрачные порты.
2. Используются виртуальные com порты Moxa Nport для физических линий связи и TCP порты для gprs.Обе системы сбора позволяют работать в режиме TCP сервера, поэтому можно перевести виртуальные COM порты в Moxa в режим TCP клиента, чтобы свести решение задачи в распараллеливание только TCP портов.
Не важно, виртуальный порт или прямое соединение TCP клиента — важно, что на другом конце RTU(ASCII) устройство.
Опросить устройство двумя мастерами в данном случае можно только двумя способами.
1. строго в разное время
2. создав шлюз (кто будет выступать шлюзом уже дело десятое, либо это преобразователь протокола MGate с несколькими сокетами и самостоятельно опрашивающий RTU устройство, либо какое-то программное решение).кстати на счет MGate не очень уверен, не попадалось в руки.
1. Думаю лучше делать универсальное решение, полностью прозрачные порты.
Интересная и сложная задача. Коммуникатор 6-й версии позволяет обращаться к общим данным из исходного кода разных линий связи. Нужно реализовать хаб для перенаправления и синхронизации запросов и ответов.
Использование Коммуникатора в качестве основы ускорит разработку, т.к. Коммуникатор предоставляет:
— готовые каналы связи,
— теги, в которые можно выводить состояние связи и вспомогательную информацию,
— журналирование.Будем рады разработать на заказ. Если будете разрабатывать самостоятельно, расскажите о процессе и результате.
Спасибо за ответ. Пока что не знаю разрабатывать или нет.
Нашел программку, которая разделяет TCP порт на несколько портов, потестирую триальную версию, посмотрим как будет работать. Может это вообще нежизнеспособно.вопрос как контролировать в WEB что линия запущена/остановлена ?
Тег, который всегда будет больше нуля, если линия запущена. Например, мгновенное значение чего-либо, например, температуры. И по формуле определять истина или ложь. 😅
Шутка.
Ну это не совсем тот метод, что хотелось бы 🙂
Нужен канал Status для линии как сделано для устройств. Работает/не работает
типа LineStatusМожет есть зарезервированное имя тега для этого?
Потребуется привязывать канал к линии. Не очень удобно, но пока других идей нет. На данный момент не реализовано, но функция нужная, поэтому со временем появится, надеюсь.
Как-то все половинчато реализовывается 🙂
Сделали статус для Устройства, сразу логически напрашиваются статусы для Линии и для Коммуникатора, если он удаленный…
Статус должен каким-то образом передаваться в канал. Вопрос заключается в том, как наиболее удобно привязать этот канал.
Может быть что-то типа битовой маски. Чтобы в каждом устройстве в теге Status шел составной сигнал: Статус коммуникатора, статус линии, статус устройства.
Идея для размышления.
Если канал работает, значет он посылает логи серверу. Мы же в админке видим эти логи. Значит если канал работает, значит логи поступают. Отсюда надо смотреть приходят логи по каналу — значит канал запущен. 😂Статус линии не совсем правильно в бите, так как на линии может быть несколько устройств.
Как бы да, линия логируется, значит ее можно так же добавить в канал, хоть ручками…
Но тут фокус — мы ставим по аналогии с устройством StatusLine — для сервера это код тега устройства, то есть его надо научить, что этот зарегистрированный код тега не в устройстве, а в Линии
- Вы должны авторизироваться для ответа в этой теме.