МКОН 24 не опрашивает больше двух устройств

[Валенок]

..
я экспериментировал на обычном преобразователе интерфейсом Ethernet-RS485, опрашивая ПР200 (всего одно устройство) двумя scada системами.
1. надо синхронизировать время двух ПК
2. надо настроить периоды опроса таким образом, чтобы одна система опрашивала каждые 10 минут например но в минуты часа :00, :10, :20 и т.д.
а вторая система так же выполняла опрос каждые 10 минут но в минуты часа :01, :11, :21 и т.д.
..

Если бы про самый низ ethernetа:
1. Не надо
2. Прослушивание и рандомные паузы. Разрешение коллизий. До нас. 1974 год

..Как тут МКОН работает и главное как верхние системы большой вопрос

Т.к. тут очередь (все утверждают, я не против), то видимо так:
Есть почтальон(1) на велике и склад посылок(2) куда возят почту чоткие пацаны(3) из разных раёнов на заниженных ладах .
1. Мастер на rs (Приехал. Посмотрел. Взял одну. Повёз)
2. Очередь
3. Коннекты

[melky]

Валенок при чем тут паузы и коллизии ethernet если мы рассматриваем преобразователь в рамках подключенных к нему RTU устройств?

я делаю второй запрос, а там прёт ответ от RTU устройства первому запрашивающему, и преобразователь ему такой, НА тебе опять пакет RTU, че ты тут мне шлешь? Примерно как на линию RS подключить два мастера сразу с циклическим опросом.

[Валенок]

при чем тут паузы и коллизии ethernet если

не раглядел про

а обычном преобразователе интерфейсом Ethernet-RS485,

Показалось что просто 2 мастера в одной сети

Примерно как на линию RS подключить два мастера сразу с циклическим опросом.

Тогда б как с коллизиями




Про почтальона и поцанов - в силе.

[melky]

Валенок с двумя мастерами аналогично, в моем случае та же синхронизация времени между ПК и разнесение опроса по времени. У двух ПК будут например USB-RS485. Сути не меняет. Эксперимент в этом и заключался, заставить работать двух мастеров при одной линии RS на хвосте.
Если добиться синхронизации времени у 2-х ПЛК можно сделать аналогично. По крайней мере на многих ПЛК есть возможность синхронизации времени.
Или там можно проще, один прочитал, передал на чтение другому и так по кругу.

[Валенок]

заставить работать двух мастеров при одной линии RS на хвосте.

Клиентов при "преобразователе интерфейсом* Ethernet-RS485,"?
*и протокола?

Если добиться синхронизации времени у 2-х ПЛК можно сделать аналогично

При нормальной очереди - не требуется.

[melky]

Валенок да не важно, Ethernet-RS или USB-RS485, я кажется и то и то цеплял для тестов. МКОН у меня нет, хотя и его можно, все равно ПК опрашивает через него.

Где ж тут нормальная очередь, если устройства разные?

[Валенок]

Где ж тут нормальная очередь,

Вроде как определили что у МКОН есть очередь?

Если любой преобразователь (мобас-tcp/модбас-RTU) запросы от любого кол-ва модбас-клиентов в одну rs не ставит в очередь, то этот преобразователь - какашка. Не?

Где ж тут нормальная очередь, если устройства разные?

Не уловил сути вопроса.
Нормальность - это к организации самой очереди, сколько устройств (клиентов по tcp/слейвов по rs) не имеет значения.

[imaex]

Если любой преобразователь (мобас-tcp/модбас-RTU) запросы от любого кол-ва модбас-клиентов в одну rs не ставит в очередь

А такие вообще бывают? melky писал про конвертор eth/rs, там с сериализацией вообще проблемы, принципиальные, кмк. Я так думаю, что там проблемы вообще не на 100% разрешимые, когда у вас со стороны rs не modbus, а произвольный протокол. Хотя, то же melky упоминал про моксовский дивайс, где такое как бы гарантируют. Но, я лично с такими дела не имел.

МКОН, если что, тоже в таком режиме умеет работать, т.е. без преобразования протокола.

[Валенок]

А такие вообще бывают?.

А в чем проблема сериализации протоколов вида запрос/ответ (пусть про модбас конкретно)? Задача то простейшая. МКон же с очередью? А очередь и есть сериализация

[imaex]

А в чем проблема сериализации протоколов вида запрос/ответ (пусть про модбас конкретно)? Задача то простейшая. МКон же с очередью? А очередь и есть сериализация

Очередь в режиме шлюза tcp/rtu, там протоколы с обеих сторон предопределены. Как тот же МКОН будет работать в т.н. "режиме прозрачного шлюза" (так в документации), т.е. eth/rs - я не знаю. Во всяком случае с другим (не МКОН) преобразователем я на стороне клинта запросто получал данные, запрошенные другим клиентом. Хотя со стороны rs и банальный modbus был. А вот в режиме шлюза tcp/rtu - всё красиво и вообще без вопросов.