|
|
Опрос устройства OPC сервером |
|
Здравствуйте. Разрабатываю OPC сервер для нашего оборудования.
Прошу поделиться соображениями - вопрос в следующем. OPC сервер с заданной частотой получает данные от аппаратуры. "Мост" между OPC и оборудованием - dll-ка с функциями доступа к данным. Если вручную запустить OPC сервер, начнется периодический опрос устройства. Теперь к сути вопроса. OPC-клиент может в любой момент пожелать принудительно прочитать набор переменных - неважно, синхронно или асинхронно. Я не пойму, как это согласовать с внутренним режимом опроса устройства OPC сервером? Чтение данных с устройства занимает в среднем 20 сек, и как должен реагировать сервер, если в то время, как он читает данные с оборудования, поступает синхронный/асинхронный запрос от клиента на чтение переменных? Если чтение требуется из КЭШа - понятно, выдасть уже прочитанные данные... а если указан параметр OPC_DS_DEVICE? Еще один вопрос. OPC сервер при опросе устройства читает сразу несколько блоков данных - статус аварий, статус модулей и т.п. Клиент же может запрашивать ограниченный набор переменных, то есть он подразумевает, что читаться будут только они. Но при поступлении такого запроса на сервер будут читаться все данные , а на это требуется больше времени. Состояние аппаратуры описывается множеством переменных, и библиотека для работы с устройством содержит всего 3 функции для чтения всех этих данных. Не разрабатывать же для чтения каждого параметра свою функцию, которую можно бы было вызывать при запросе клиентом определенного параметра? |
|
 |
|
|
OPC_DS_DEVICE - это вообще в принципе зло. Вы еще не все проблемы возникающие осветили. Клиентов может быть несколько и доступ к оборудованию становится узким местом. В такой ситуации синхронный однопточный доступ к оборудованию и предоставление данных из кэша дает выигрыш в скорости доступа к произвольным данным как ни странно это может показаться на первый взгляд. "Затуркают железяку". Так что я думаю что тут ложь во спасение. Еси юзер не внемлит, что 500 тегов нельзя получить через COM раз в 200 мс то ему в кэш самая дорога... даже в режиме OPC_DS_DEVICE
|
|
|
|
|
Согласен, что заказчик должен понимать что не все получается "за так". Самое простое - опрос всех всех данных, которые могут понадобиться клиенту, по расписанию (после первого чтения измеренного значения читаем скажем уставку 1, потом опять измеренное значение, потом уставку 2, потом опять измеренное значение и т.д. Как все траебуемые параметры вычитали - переходим к началу этого кольца). Измеренные значения с флагами ошибок читаем постоянно, а остальные параметры потихоньку вычитываем с гораздо большим интервалом времени. При этом, естественно, клиент будет получать последнее годное значение. Иначе задача превращается в написание обмена "с поведением". При поступлении запроса на чтение чего-то такого, что не является текущим значением, надо будет дождаться завершения обмена и послать новый запрос и тут еще чудеса будут при неответах и переспросах. В принципе, все это пишется и вот недавно писали что-то такое |
|
|
При экспериментах ни один чайник не пострадал
----------- Плохому системному интегратору всегда OPC сервер мешает. ______________ Пишу на C++ за еду |
|
|
|
|
Спасибо за Ваши ответы. "ему в кэш самая дорога... даже в режиме OPC_DS_DEVICE " - в принципе к этому я и склонялся, но хотелось услышать мнения |
|
|
|
Ответить 
|
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
Но экстрим в этом есть.