В филиале ставить преобразовательиз RS232/485 в Ethernet,
маршрутизировать на такой же преобразователь в центральном офисе и в COM-порт сервера. Но, так как
общее количество счетчиков порядка 500, придется ставить много
преобразователей. И к тому же на один COM-порт сервера очень большая нагрузка.
Правильное программное обеспечение может и должно работать через транспорт TCP/IP для опроса счетчиков напрямую, без создания виртуальных портов.
Могу предложить любое решение от нас - АИИС ЭНТЕК чисто для создания системы учета, SCADA ЭНТЕК для диспетчеризации, OPC-сервер или шлюз в МЭК-104 для опроса счетчиков и выдачу данных в сторонние системы. Все эти решения у нас есть, опрос счетчиков производится просто по IP-адресу шлюза. Если надо - также можно предложить решение и когда работа идет через динамический или серый IP-адрес, с установкой соединения снизу, от объекта.
То есть Вы предлагаете следующую схему:
Счетчик в преобразователь RS232 в TCP/IP - маршрут на сервер - на сервере ПО, которое видит пакеты и обрабатывает?
Первоначально опубликовано DirectRaw
Счетчик в преобразователь RS232 в TCP/IP - маршрут на сервер - на сервере ПО, которое видит пакеты и обрабатывает?
Если средствами вашей закрытой сети можно обеспечить такую схему - то да, она будем самой удобной, со статическими адресами на уровне объектов. При этом никакие пакеты сами по себе не ходят - сервер сбора данных из центра устанавливает с объектами ТСР соединение по заданному порту, и по этому соединению далее идет опрос в протоколе обмена счетчиков ЭЭ.
Для целей учета соединение будет устанавливаться не постоянно, а с какой-то периодичность. Для целей мониторинга - можно опрашивать постоянно.
Т.к. на один С2000 по сети можно подвизать 10 других С2000, на приемной стороне строим пирамиду сводим все к одному С2000 и всё заводим на один COM порт сервера!
Хотел узнать Ваше мнение. Работоспособна ли такая схема?
Первоначально опубликовано DirectRaw
Оказывается мы уже закупили C2000 Ethernet (Болид) в больших количествах.
... Т.к. на один С2000 по сети можно подвизать 10 других С2000, на приемной стороне строим пирамиду сводим все к одному С2000 и всё заводим на один COM порт сервера!
Фиговая схема. И сам этот C2000 тоже какой-то стремный.
Нормальный преобразователь должен уметь работать в режиме TCP-сервер, когда он ожидает входящее соединение сверху. Так работают Моксы, Адамы. Этот же C2000 судя по описанию может работать только в режиме UDP - то есть когда транслирует все UDP-пакеты, приходящие сверху на заданный порт UDP, в 485 порт, а из 485-го - наружу тоже по UDP, на адрес и порт сервера.
Как это все заставить работать - уже думайте сами. Но гемор будет. И ПО верхнего уровня тоже как будет работать надо смотреть.
Т.к. на один С2000 по сети можно подвизать 10 других С2000, на приемной стороне строим пирамиду сводим все к одному С2000 и всё заводим на один COM порт сервера!
Жуть неимоверная. "Пирамида" из преобразователей. 500 счетчиков. Один последовательный порт. И, видимо, ТМ наверху.
Могу только пожелать удачи и порекомендовать изучить подробно документацию на ваши счетчики. Протоколы обмена, работающие через последовательные линии, очень редко позволяют работать одновременно более чем с 255 устройствами на шине. Так что, очень может быть, что затея с "одним портом" на сервере изначально обречена. Возможен вариант - приобрести плату для сервера с кучей физических последовательных портов и избавиться хотя бы от пирамиды из преобразователей. Так, по крайней мере, вы распределите обмен по нескольким потокам данных.
Теория - это когда все знаешь, но ничего не работает.
Практика - это когда все работает, но никто не знает как.
Первоначально опубликовано DirectRaw
Т.к. на один С2000 по сети можно подвизать 10 других С2000, на приемной стороне строим пирамиду сводим все к одному С2000 и всё заводим на один COM порт сервера!
Хотел узнать Ваше мнение. Работоспособна ли такая схема?
Мнение: бывает и хуже. Конечно, проще и дешевле было бы купить велосипед в магазине, чем изобретать собственный. Но живем мы в России и к тому же это технический форум, так что перейду к техническим проблемам предложенной схемы.
В такой схеме каждый счетчик будет получать все запросы сервера, в т.ч. и адресованные другим счетчикам. А упомянутые Вами CE303 и Меркурий (если имеется в виду M23х) имеют разные основы протокола (IEC1107 и Modbus-RTU, соответственно). В приличной системе их разводят по разным шинам, чтобы исключить вероятность ответов на чужие запросы. Но если очень уж хочется собрать на коленке что-нибудь кое-как работающее из имеющегося на складе хлама, то следует по крайней мере не назначать Меркуриям адреса, с которых могут начинаться пакеты СЕ303 (1, 2, 6, 47 - возможно, список не полон, пишу по памяти).
M23x имеют однобайтовый адрес, поэтому их в такой схеме не может быть больше 249 (256 минус служебные - 0, 254, 255 - минус конфликтующие с IEC1107 - см.п.1).
В такой схеме нет возможности динамически управлять скоростью приема/передачи. Так что не забудьте либо заранее во всех СЕ303 сконфигурировать рабочую скорость равную начальной (по умолчанию они разные - 9600 и 300), либо заставить опрашивающую программу отказываться от переключения на рабочую скорость.
Если не ошибаюсь, размер буфера С2000 - 255 байт. У опрашивающей программы из-за этого возможны проблемы, поскольку некоторые пакеты CE303 могут быть значительно длиннее. Возможно, придется отказаться от чтения журналов и предпринять дополнительные меры для ограничения объема разовых порций для других данных.
В такой схеме счетчики могут опрашиваться только последовательно. Не зная деталей, трудно говорить о продолжительности цикла, но порядок прогнозирую в районе нескольких часов (тогда как хорошо построенная система легко могла бы уложиться в минуту)
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме
