Запись OWEN OPS сервером BOOL тегов в модуль МУ210-403 , как ?

За установку 24 выходов модуля отвечает 32 битный регистр по адресу 470. Модуль понимает только команды чтение и запись этого регистра как сразу два регистра 470 и 471 в одной команде, по отдельности их читать и писать нельзя. Если при чтении OWEN OPS сервер обЪединяет чтение этих двух регистров одной командой и все ОК, то при записи он упорно их пытается писать по одному, соответственно выдает ошибку. Подскажите можно как то настроить принудительно запись сразу обоих регистров, кроме как писать все одним тегом DWORD или это ограничение OWEN OPS сервера и придется городить костыли?

Если используется функция записи 0х10, то запись нескольких последовательных регистров должна выполняться одним запросом

1exan если в функцию 0x10 подали один регистр, сколько регистров она запишет последовательно? :)

Цитата:

---

Сообщение от melky

1exan если в функцию 0x10 подали один регистр, сколько регистров она запишет последовательно? :)

---

Я не знаю, как OPC формирует запросы, но еcли у двух последовательно стоящих регистров OPC указана функция 0x10 , то наверное они должны попасть в один запрос

Цитата:

---

Сообщение от melky

1exan если в функцию 0x10 подали один регистр, сколько регистров она запишет последовательно? :)

---

Если в OPC отключено использование записи единичного регистра, то он сам должен подставлять в запрос кол-во подряд идущих регистров. Явно там не настраивается.

imaex , хорошо, если мы включаем режим записи по изменению, как должен отреагировать OPC в таком случае?

з.ы. не пользуюсь OPC в принципе по возможности. Особенно на машине с отсутствующим локальным пользователем (есть только доменный) при работе с OPC Овен у меня получается кто первым запустил OPC тот и получает данные, так как вроде один и тот же пользователь почему то имеет разные uuid запуская процессы от разного ПО. Овен отмолчался по данной ситуации и не смог ничего ответить.

Скорее всего причина в том, что ОРС вызывает функцию записи по изменению тега, а если тег не один 32 битный, а два по 16 бит, то при изменении значения только одного он и отправляется на модуль

В общем-то в руководстве написано, что управление именно UINT32, а не 2 по UINT16

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

Цитата:

---

Сообщение от melky

з.ы. не пользуюсь OPC в принципе по возможности. Особенно на машине с отсутствующим локальным пользователем (есть только доменный) при работе с OPC Овен у меня получается кто первым запустил OPC тот и получает данные, так как вроде один и тот же пользователь почему то имеет разные uuid запуская процессы от разного ПО. Овен отмолчался по данной ситуации и не смог ничего ответить.

---

Локальный пользователь есть всегда, как минимум - SYSTEM. Для подобных случаев оптимальным, кмк, будет выполнение процесса OPC в кач-ве службы. У овеновского регистрации в кач-ве службы я не увидел. Наверное, потому и отмолчались. Конкретно овеновским я не пользуюсь, держу чисто для коллекции/сравнения. Очень уж он тормознутый. А так - да, OPC нужно использовать только за неимением других вариантов.

imaex ну вот Scada у меня запускалась от SYSTEM и я получал данные, открываю сам OPC а там по нулям все.
Или наоборот, запускаю сперва OPC и смотрю в ней данные, запускаю Scada а там нули...

То есть первый запущенный не давал получать данные второму. Все, что увидел, это то, что пользователи имеют разные uuid. Списал на такое поведение доменного пользователя и снес к чертям такой OPC.
Все мои попытки настроить DCOM не увенчались успехом, добавления пользователей, разрешения и прочее, "разные" пользователи запускают и все тут.

Я выше уже написал:

Цитата:

---

Для подобных случаев оптимальным, кмк, будет выполнение процесса OPC в кач-ве службы.

---

Только не "оптимальным", наверное, а единственно верным. Скорее всего. Возможно ли это конкретно для овеновского -не знаю.