2 trofim
Если все машины с RunTime будут висеть в одном сегменте сети, а данные для всех 10 клиентов будут идти из одного и того же источника, работать не будет. Сеть ляжет и умрёт.
Именно по этой причине рекомендую клиент-серверную FactoryTalk View SE. Кстати, очень вероятно, что при 10 клиентах будет заметно дешевле, чем устаревшая RSView32, а уж быстрее - так это точно. _________________ Обращайтесь к профессионалам.
2 trofim
Если все машины с RunTime будут висеть в одном сегменте сети, а данные для всех 10 клиентов будут идти из одного и того же источника, работать не будет. Сеть ляжет и умрёт.
The road to hell.
oldDad писал(а):
2 trofim
Именно по этой причине рекомендую клиент-серверную FactoryTalk View SE. Кстати, очень вероятно, что при 10 клиентах будет заметно дешевле...
Если не всем клиентам требуется управление (т.е. клиент ViewOnly) - заметность будет очень существенной.
А, удобство внесения изменений в проект - один или 10 "Думайте сами, решайте сами, иметь или не иметь."
Схема скада приблизительно такова: порядка 7 рунтаймов на нижнем уровне, по одному на объект (сбор информации управление объектом, прогр.контроллеры не используются только сторонние ОРС серверы, модули ICP и тд ), второй уровень 2 рунтайма у диспечеров выборочная информация, отчеты об авариях, архивирование выборочных данных, верхний уровень 1 рунтайм обобщеная информация от диспечеров типа (сколько угля завезли, сколько сожгли, сколько гиков выдали, отчеты об авариях.--- вот мои мысли, если че не так, направьте на путь истенный.
Понимаете, RSView32 построена так, что все в базе данных постоянно сканируются, циклически, каждую секунду или несколько секунд. Все эти тэги постоянно поступают по сети в RSView32.
Если у Вас в одном сегменте сети несколько копий RSView32, то ни одна из них не знает о своих соседях в сети, лезет в сеть и собирает тэги независимо от других. Каждая машина, не подозревая о таких же машинах рядом с собой, постоянно раз в секунду или в несколько секунд получает себе в базу копии всех тэгов.
Если машин, например, 3, то один и то же тэг будет запрашиваться у источника информации три раза, один за другим. Если машин 7, то один и тот же тэг будет запрашиваться 7 раз подряд.
Это создаёт колоссальную нагрузку на сеть. Если Вы хотите иметь хоть какую-то нормальную динамику сети, то есть такое правило: если в сети более трёх идентичных машин, запрашивающих одно и то же, то настоятельно рекомендуется клиент-серверное решение, при котором тэги с источников собирает только одна машина (сервер), а остальные машины - клиенты - висят на другом сегменте сети и получают информацию от сервера. _________________ Обращайтесь к профессионалам.
Втомто и дело ,что нижний уровень каждый рунтайм -законченный объекти значения тегов обнавляются из сторонних серверов устаноыленных локально(3 ОРС сервера + рунтайм машина не тормозит ,работает в легкую),средний уровень 1-2 рунтайма будут получать зн. тегов из нижних серверов RSView по сети и причем выборочно----- неужели сеть не пойдет???
Машины "среднего уровня" будут получать информацию от машин "нижнего уровня", т.е. машины "нижнего уровня" будут являться серверами для машин "среднего уровня", я правильно понял? _________________ Обращайтесь к профессионалам.
Именно так, а также машины нижнего уровня клиентами к сторонним ОРС серверам установленным локально, по идее должно работать. Наше предприятие разбито на несколько объектов со своим обслуживающим персоналом, поэтому подразумевается централизация управлением каждого объекта (индивидуально) + текущий мониторинг процессов и оборудования и сбор выборочной информации с каждого объекта к центральному диспечеру.
Последний раз редактировалось: trofim (Пт 15 Янв, 2010 16:33:50), всего редактировалось 1 раз
Схема скада приблизительно такова: порядка 7 рунтаймов на нижнем уровне, по одному на объект (сбор информации управление объектом, прогр.контроллеры не используются только сторонние ОРС серверы, модули ICP и тд ), второй уровень 2 рунтайма у диспечеров выборочная информация, отчеты об авариях, архивирование выборочных данных, верхний уровень 1 рунтайм обобщеная информация от диспечеров типа (сколько угля завезли, сколько сожгли, сколько гиков выдали, отчеты об авариях.--- вот мои мысли, если че не так, направьте на путь истенный.
Не заморачивайся с RSView32, делай на Factory Talk View SE.
Но тебе будут нужны 7 HMI серверов, весь проект будет как одно целое.
Сделай эксперимент.
Два компьютера c RSView32:
1) Нижний, имеет RSView32 и необходимые OPC серверы, OPC сервер самого RSView32 включен.
2) Средний, имеет RSView32 и данные (теги устройств) берет из нижнего RSView32. Иными словами связь по цепочке.
Нижний на момент пуска проекта RSView не должен иметь связь с устройствами, т.е. теги в ошибке. Включи средний, когда он получит данные из нижнего (можно узнать по какому нибудь тегу памяти нижнего) включай связь.
Для версий RSView32 6.30.16 (17) - 100% падение связи между нижним и верхним, лечилось заменой CmeOPC32.exe на какой-то из заплатки (отдельно храню его) в нижнем компьютере.
В более поздних версиях RSView32 тот-же эффект, хотя версия CmeOPC32.exe уже старше.
Добавление еще одного компьютера в цепочку (верхний берет данные из среднего) еще хуже (это пробовали уже ради баловства).
Падение проявляется при первом переходе тега из Bad в Valid, если средний успел увидеть Valid, тогда проблем не возникает.
Ответ от Rockwell (я им дал эти простенькие проекты для демонстрации эффекта) гласил что так не надо делать (т.е. не должно быть цепочки OPC), рекомендовали использовать RSLinx Gateway.
Во-первых проекты для нижних уровней почти готовы, осталось конвеерные и скребковые линии добить, С Супер вижен у меня пока не получается, слишком наворочено, готовый проект созданный в ворксе импортировал, но теги не получают значений из сторонних серверов, и адресацию проверял и по-новой прописывал, бесполезно и вдобавок чтобы проверить проект каждый раз запускать клиента.... короче буду пытать RSView 32, попробую менять врема (скважность) сканирования базы тегов, на верхнем уровне необязательно получение информации в реальном времени. А пока все на голом энтузиазме, у конторы даже нормального монитора не выпросиш. А версию использую 7.40 была 7.10 глючила, не поддерживала русский шрифт , одни крокозяблики. Жаль скриншет выложить нельзя, набросал сегодня межд упрочим.
Иеще,помогите если можно ,нужен алгоритм,нужно организовать защиту на логических тегах (запуск одного устройства -две кнопки ON,OF -лог. тег D11, и второе устройство также ,лог.тег V11 -- нужно организовать запрет остановки одного без предварительной остановки другого ,и наоборот запрет запуска второго без предварительного запуска первого,но запуск и остановка не одновременно)помогите исли можно,в голову ниче не лезет.
Иеще,помогите если можно ,нужен алгоритм,нужно организовать защиту на логических тегах (запуск одного устройства -две кнопки ON,OF -лог. тег D11, и второе устройство также ,лог.тег V11 -- нужно организовать запрет остановки одного без предварительной остановки другого ,и наоборот запрет запуска второго без предварительного запуска первого,но запуск и остановка не одновременно)помогите исли можно,в голову ниче не лезет.
Этот вариант я рассматривал,он не впалне подходит для оператора,может чтото типа производного тега с логическим выражением ,и к примеру при по пытке запуска или остановке всплывала подсказка(видимость.невидимость)
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.140 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
