Сетевые мьютексы

[melky]

Не важно, сколько там мастеров при сквозном шлюзе, узкое место RS485, где связь сквозь шлюз к устройству только от ОДНОГО мастера (пусть он будет хоть трижды TCP) в один момент времени. Ни больше, ни меньше. Более умных шлюзов, которые отдают данные из регистров Modbus TCP я редко видел, и стоят они на порядок дороже. Где шлюз сам опрашивает RTU slave устройство и формирует карту регистров для TCP устройств.

А что тут подробнее ? если вам надо опрашивать устройство с двух ПЛК, выполните как вы и описали выше опрос, используя общую переменную между ПЛК. Один читает, второй ждет, и так далее. То есть организуйте мютекс сами, ну и не использовать Конфигурации, если речь идет о ПЛК Овен.

[Devoter]

Не важно, сколько там мастеров при сквозном шлюзе, узкое место RS485, где связь сквозь шлюз к устройству только от ОДНОГО мастера (пусть он будет хоть трижды TCP) в один момент времени. Ни больше, ни меньше. Более умных шлюзов, которые отдают данные из регистров Modbus TCP я редко видел, и стоят они на порядок дороже. Где шлюз сам опрашивает RTU slave устройство и формирует карту регистров для TCP устройств.

А что тут подробнее ? если вам надо опрашивать устройство с двух ПЛК, выполните как вы и описали выше опрос, используя общую переменную между ПЛК. Один читает, второй ждет, и так далее. То есть организуйте мютекс сами, ну и не использовать Конфигурации, если речь идет о ПЛК Овен.

Речь не об одном моменте времени. Возможно, не совсем корректно описал ситуацию. Положим, есть устройство, управляемое через релейный модуль, к примеру, которое управляется с двух разных точек через разные ПЛК, при этом, нам нужно сделать так, чтоб они работали независимо, то есть в любой момент времени один может быть недоступен, хотя согласование между контроллерами - действительно, логичное решение. Чтобы сеть не нагружать, постоянно опрашивая устройство, контроллер получает значение уставки только при запуске, а в остальное время просто запоминает - что он туда послал, то есть не ведет опрос и запись постоянно. И нельзя гарантировать, что не возникнет следующий сценарий:

1. контроллер A перед записью прочитал текущую уставку (0000 0000)
2. контроллер Б перед записью прочитал текущую уставку (0000 0000)
3. контроллер A обновил уставку (0001 0000)
4. контроллер Б обновил уставку (0000 0001, хотя должно быть 0001 0001, но ПЛК Б не прочитал обновленную уставку)

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

а) а чем пустой регистр будет отличаться от регистра с уставкой если лочить его будут мастера?
б) предлагаете вместо одного запроса более трех делать, а сети выдержат если трафик будет увеличен?
в) даже если используется модное слово мьютекс: а разве не затерётся бит, который записан при их использовании при такой интерпретации
г) может для промавтоматики и придумали ОРС сервера, чтоб клиенты не общались на прямую с модулями и не приходило в голову внедрять мьютексы

Не важно, будут ли его лочить в момент чтения/записи, об этом как раз ответ на предыдущее сообщение. Слово мьютекс не модное, термину больше 50 лет. Возможно, вы неверно поняли, опрашивать как раз постоянно не надо, так что 3 запроса подряд, вместо постоянной записи и чтения явно разгрузят сеть, а не загрузят, ну и OPC - это немного из другой оперы, применяется при другой схеме сети и для других задач. Суть в том, чтобы построить распределенную сеть на modbus.