Протокол ОВЕН и ModBus на одной шине

[Efremov]

Такой вопрос, возможно даже кто то пробовал это:
в одной физической сети (2 провода А и В) организовать 2 сети по протоколу ОВЕН и ModBus, опрашивать разными ОРС с разных преобразователей интерфейса, с разных портов.
Преследуемая цель, разделить устройства опроса (информационная часть) и устройства управления механизмами, для уменьшения времени реагирования устройств управления, т.к. в сети много устройств и опрос ОРС сервера вырос до 10 сек., тоесть отсылаешь команду открытия клапана и ждешь) Мастер в сети только скада.

[melky]

Невозможно, у вас будут накладываться данные от чужих запросов и ответов.
Всегда будет происходить совпадение времени, от этого не избавиться.

[melky]

ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.

[Сергей0308]

ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.

Ну и зачем постоянно писать "0" или "1" при дискретных сигналах?

[melky]

Сергей0308 имеется ввиду те каналы, на которых управление читать максимально быстро. и там же запись.
Ведь ОРС пока не дочитал данные не будет выполнять запись, а там пачка сигналов читается в очереди.

[Efremov]

ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.

OPC сервера ОВЕН

[melky]

Efremov я к сожалению не особо с ним знаком, на компе в домене он криво у меня работает. Посмотрите в его настройках, можно ли там указывать время опроса для разных каналов. На группы там точно можно делить. в общем все вялотекущие сигналы опрашивайте реже. например постоянно опрашивайте важные и реже не важные из расчета времени так, чтобы было минимум совпадения времени. Тогда при подаче команды управления есть шанс, что она выполнится быстрее, если в это время не было опросов не важных параметров.

Хотя с протоколом Овен не помню, кажется он не поддерживает групповых запросов как Modbus.

[Efremov]

Невозможно, у вас будут накладываться данные от чужих запросов и ответов.
Всегда будет происходить совпадение времени, от этого не избавиться.

тоесть будут совпадать частоты 2 х разных преобразователей интерфейса? но ведь разные протоколы передачи данных, даже можно сделать что бы адреса устройств не пересекались в 2 х разных сетях.

[melky]

Efremov частоты и протоколы тут не важны, важно время и свобода линии. Вот например одна сторона сделала запрос прибору и ждет ответа, вторая сторона не знает, что линия сейчас будет занята и тоже посылает запрос, в это время первый прибор начинает отвечать и второй прибор начинает отвечать, в результате на линии мусор.

Я пробовал проводить эксперимент только я двумя SCADA системами опрашивал один прибор, расшарив COM порт на две линии TCP, там такая каша начинается.
а на каждый прибор ставить свой TCP шлюз с поддержкой нескольких сокетов это накладно. Если бы приборы были c TCP протоколом то это одно, а когда это линия RS485 то ничего хорошего не выйдет. Время опроса и ответа как бы вы не разносили всегда периодически совпадает.

[Efremov]

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

10 сек - это, простите, очень до хрена - у вас там 5 тыщ датчиков ?
Поподробней

Все просто, датчиков всего 140 штук, все приборы формы ОВЕН, протокол фирма ОВЕН, ОРС фирма ОВЕН , опрос идет в порядке очереди, в ОРС есть отладочное окно в котором в котором все отображается, сам ОРС пишет что опрос всех параметров занимает порядка 13 000 ms, в ОРС время опроса выставлено 100 ms, все как бы складывается