Dima
Forum Member / Участник форума
Участник № / Member № 839
отправлено / posted
Здравствуйте! Наше предприятие приобрело Double Force. Возможен ли переход с обычного МРВ на Double Force без внесения в проект каких-либо изменений.
Сообщения / Posts 33 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Да - в самой структуре узла АРМ ничего при этом менять не нужно. Double Force МРВ это тот же самый МРВ, только с поддержкой некоторых функций горячего резерва на уровне узлов.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Dima
Forum Member / Участник форума
Участник № / Member № 839
отправлено / posted
Попробовал перевести проект под Double Force (всё действия в соответствии с Руководством пользователя). В узел были добавлены каналы: 1)Канал типа Input подтип "Системный" дополнение "Статус" отображающий состояние сервера. 2)Аналогичный канал, но типа Output. 3)Канал подтипа ДИАГНОСТИКА с дополнением ДУБЛЬ 4) Канал подтипа СИСТЕМНЫЙ с дополнением ПРИОРИТЕТНЫЙ. Для всех каналов узлы были установлены флаги "В сеть". Затем был создан резервный узел. На первом сервере запускаю профайлер, Double Force и загружаю основной узел. Тоже самое на втором сервере, но узел Резервный. Показания каналов на первом сервере: 1)Состояние - работа 2)-"- 3)Нарастающее 16-тиричное число 4)Значение показывающее наличие партнера со статусом работа.
Показания каналов на втором сервере: 1)Состояние - работа 2)-"- 3)Нарастающее 16-тиричное число 4)Значение показывающее наличие партнера со статусом работа. При попытке на втором сервере установить его в "резерв" в резерв переводятся оба сервера и наоборот. То есть оба сервера или в работе или в резерве. Что я сделал неправильно и какие особенности не учёл?
Сообщения / Posts 33 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1) Немного не понятна процедура "На первом сервере запускаю профайлер, Double Force и загружаю основной узел." - Вы грузите узлы в Профайлере Инструментальной системы или сервер запускаете из инструменталки, а консоль из Double Force МРВ?
Итак - немного об особенностях: 1) Между ПК должен быть доступ по сети как на файловом уровне, так и на уровне DCOM. 2) При запуске двух DF МРВ HASP-ключь должен быть от DF МРВ. Никакие больше ключи вроде инструментальной системы в ПК стоять не должны иначе при запуске МРВ не разрешит использовать функций DF МРВ, а запуститься как обычный МРВ. 3) На ПК с DF МРВ должно быть синхронизировано системное время. 4) В проекте у Вас должен быть хотябы один канал с автопосылкой в сеть (например, генератор пилы). Вроде все основные требования, но самое главное из них - это №2... Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Dima
Forum Member / Участник форума
Участник № / Member № 839
отправлено / posted
Хорошо. Может быть я чего-то не понимаю....
Все 3 машины в одной сети через хаб. DCOM настроен(проверялось так: на одной машине MPB, на другой NetLinkLight, запускался тестовый проект с 2-я узлами - все работает на каждой из 3-х машин)
Создаем проект: 1) Создаем узел df("без автопостроения"-средний), в нем создаем канал("pila") тип пустой, дополнение - G_пила. Ставим "в сеть" и доступ
2) Создаем узел arm("без автопостроения"-средний) делаем "связать с объектами узла" и выбираем объект "База" узла df
3) Затем выбираем узел df делаем "создать резерв".
Проверяем настройки нового узла "df(1)" В редакторе представления создаем для узлов df и arm картинки.
Сохраняем проект в общей для 3-х компьютеров папке.
Запускаем на каждой машине (№1 и №2) drawServ, потом запускаем PicRT, выбираем проект, на машине №1 узел df, на машине №2 узел df(1) соответственно
Нажимаем сначала "человечка" в PicRT, потом "run" в drawServ. Сначала на машине №1, потом на машине №2 соответственно.
Получаем :
Машина №1 - STS_WORK, число пользователей - 1, сервер мат.обработки LOCAL +"бежит" канал"pila" Машина №2 - STS_TRACE, число пользователей - 1, сервер мат.обработки LOCAL +"бежит" канал"pila", но как бы с шагом 2, т.е 6, 8, 10, ..., причем "независимо от компьютера№1"
Запускаем NetLinkLight на машине №3, выбираем в сети компьютер №1 Сразу вопрос: Какой компьютер (основной или его дубль) надо выбирать(компьютер №1 или компьютер №2)???
Выбираем проект, выбираем узел arm и жмем "человечка". Получаем: Машина №1 - STS_WORK, число пользователей - 2, сервер мат.обработки LOCAL +"бежит" канал"pila" Машина №2 - STS_TRACE, число пользователей - 1, сервер мат.обработки LOCAL +"бежит" канал"pila", но как бы с шагом 2, т.е 6, 8, 10, ..., причем "независимо от компьютера№1" Машина №3 - сервер мат.обработки Машина №1 + "бежит" канал"pila"
Выдергиваем из Хаба компьютер№1(в сети остаются компьютер№2 и компьютер№3) Получаем:
Машина №1 - STS_WORK, число пользователей - 2, сервер мат.обработки LOCAL +"бежит" канал"pila" Машина №2 - STS_TRACE, число пользователей - 1, сервер мат.обработки LOCAL +"бежит" канал"pila", но как бы с шагом 2, т.е 6, 8, 10, ..., причем "независимо от компьютера№1" Машина №3 - сервер мат.обработки Машина №1 + канал"pila" остановился
Вопросы: 1) почему Машина №2 не переходит в состояние STS_WORK? 2) почему консоль NetLinkLight не переключается на Компьютер№2?
Сообщения / Posts 33 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1) Исходя из поставленой Вами задачи - создать два резервных узла и одно дополнительное рабочее место оператора в сети, которое будет подключаться к МРВ в режиме МАСТЕР, Вам не нужно было создавать в проекте еще один узел "arm". Консоль NetLinkLight при запуске должна подключаться к уже работающему серверу в режиме МАСТЕР, и брать его же графическую бызу для отображения.
2) Переход МРВ из режима ПОДЧИНЕННЫЙ в режим МАСТЕР при потере связи с МАСТЕРОМ не автоматический, Вы сами должны управлять им через канала подтипа СИСТЕМНЫЙ_Статус. А уж как Вы это будете делать - через графику вручную по кнопке или напишете FBD, которая будет делать это автоматически - решать Вам.
3) Переключение консоли NetLinkLight на следующий сервер при потери связи с текущим происходит только в том случае, если Вы задали список этих серверов и указали таймаут переключения в специальном INI-файле проекта. Подробности смотрите в справочной системе в разделе "Работа в реальном времени"-"Графическая консоль МРВ"-"Переключение между серверами".
Одна только странность, которая пока еще остается для меня загадкой - почему у Вас генератор пилы бежит с шагом 2?
Также напоминаю Вам, что приобретенные Вами продукты ТМ до сих пор Вами не зарегистрированы. Рекомендую Вам зарегистрировать их иначе Вы не сможете получать техническую поддержку!
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Droshnev
Forum Member / Участник форума
Участник № / Member № 132
отправлено / posted
В продолжение нашего телефонного разговора, особенно момента насчет переключения статуса(режима работы) узла, вот выдержка из файла помощи:"Анализ наличия резервного узла при работе в реальном времени для автоматического переключения статуса узла;" Как же тогда понимать фразу "для автоматического переключения статуса узла"??? Почему я должен использовать FBD-программу, когда речь идет об автоматическом переключении???
И все-таки повторю вопрос: ПОЧЕМУ УЗЕЛ НЕ ПЕРЕХОДИТ ИЗСОСТОЯНИЯ STS_TRACE В STS_WORK?
И почему узел, который находился в состоянии STS_WORK после обрыва связи не переходит в состояние STS_TRACE???
Droshnev
Forum Member / Участник форума
Участник № / Member № 132
отправлено / posted
2) Переход МРВ из режима ПОДЧИНЕННЫЙ в режим МАСТЕР при потере связи с МАСТЕРОМ не автоматический, Вы сами должны управлять им через канала подтипа СИСТЕМНЫЙ_Статус.
Вопрос: Если из работы "выпадает" основной узел(скажем из-за проблемм в сети), он должен сам выходить в резерв(У нас он продолжает работать в STS_WORK)?
А уж как Вы это будете делать - через графику вручную по кнопке или напишете FBD, которая будет делать это автоматически - решать Вам.
То есть получается физический смысл DoubleForce в синхронизации атрибутов каналов и СПАД архивов??? И никаких автоматических переключений Работа/резерв.
Кто будет нести ответственность, если резервный сервер не переключится в режим работа? Разработчик FBD или разработчик DoubleForce?
У нас в проекте уже и так достаточное количество FBD-программ, многие из них написанны с использованием блоков на Техно-IL, что по вашему мнению увеличивает вычислительную нагрузку на компьютер... Как скажется введение дополнительного/дополнительных FBD-програмы(м), выполняющих столь важную функцию на надежности/производительности системы?
3) Переключение консоли NetLinkLight на следующий сервер при потери связи с текущим происходит только в том случае, если Вы задали список этих серверов и указали таймаут переключения в специальном INI-файле проекта.
Вот наш список серверов: [Servers] S1=Dispserv1 S2=Dispserv2 Timeout=5 Auto=1 Консоль так и не переключается на резервный сервер......
Одна только странность, которая пока еще остается для меня загадкой - почему у Вас генератор пилы бежит с шагом 2? Он не только бежит с таким шагом, но и имеет "другие значения относительно основного сервера", скажем на основном - 3, на резерве - 6 ...???
отправлено / posted
1) "Анализ наличия резервного узла при работе в реальном времени для автоматического переключения статуса узла;" - DF действительно автоматически АНАЛИЗИРУЕТ наличие резервного узла, но переключение MASTER/SLAVE дожно быть выполнено либо вручную, либо автоматически (через FBD) в самом проекте. Это сделано так, потому что нельзя сказать точно какие именно условия переключения должны быть реализованы в системе, у Вас они одни, а у других пользователей другие: а если перед тем как переключиться в MASTER МРВ-SLAVE перед этим должен "попрыгать" по адаптерам (если их несколько) и проверить вдруг это не MASTER упал, а просто сеть оборвалась и МРВ-MASTER продолжает нормально функционировать и не надо никуда ничего переключать по статусам - это как прикажите разрешать на автоматическом уровне?? Или, например у Вас в проекте таймаут ожидания перехода из SLAVE в MASTER - 3-4 секунды, а у кого-то перед этим должны быть выполнены определенные действия или функции, и только от успеха их выполнения нужно решить переключать SLAVE в MASTER или нет. Это может быть запрограммировано только разработчиком системы и только им, ТМ для этого дает Вам только специализированные функции и каналы для управления статусами, а сами алгоритмы функционарования системы управления статусами МРВ Вы должны создать сами!
Это ответ на Ваши вопросы: "ПОЧЕМУ УЗЕЛ НЕ ПЕРЕХОДИТ ИЗСОСТОЯНИЯ STS_TRACE В STS_WORK" и "STS_WORK после обрыва связи не переходит в состояние STS_TRACE"...
2) "То есть получается физический смысл DoubleForce в синхронизации атрибутов каналов и СПАД архивов???" Да - это действительно так. Отличие МРВ DF от обычного МРВ только в следующем: а)Синхронизация реальных значений по каналам б)Синхронизация архивов в)В комплекте идут два ключа, т.е. сразу два МРВ в одном продукте.
3) "Как скажется введение дополнительного/дополнительных FBD-програмы(м), выполняющих столь важную функцию на надежности/производительности системы?" Насчет этого можете особо не переживать - 1-2 дополнительных FBD никак не повлияют на общую производительность системы...
4) "другие значения относительно основного сервера" - это можно объяснить тем, что для этого канала Вы не задали возможность синхронизации атрибутов по Мастеру. Синхронизируемые каналы в режиме SLAVE должны быть отключены (управлением атрибутом Подключение), а кроме того - в списке автопосылок они должны быть замкнуты сами на себя.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Dima
Forum Member / Участник форума
Участник № / Member № 839
отправлено / posted
>"другие значения относительно основного сервера" - это можно объяснить тем, что для этого канала Вы не задали возможность синхронизации атрибутов по Мастеру. Синхронизируемые каналы в режиме SLAVE должны быть отключены (управлением атрибутом Подключение)
Т.е. я должен "в ручную" или с помощью того же FBD управлять атрибутом подключение? Итого получается: Если я буду решать задачу автоматического переключения серверов из резерва в работу и наоборот с помощью FBD программы, я должен создать FBD программу, выполняющую следуюшие действия : 1) постоянно следить за тем, есть ли связь с резервным сервером 2) постоянно контролировать, не повис ли Master сервер 3) переключать серверы из работы в резерв и наоборот 4) управлять атрибутом подключение каналов узла в резерве Так?
теперь вопросы по реализации: 1) как из FDB постоянно следить за тем, есть ли связь с резервным сервером? 2) как из FDB постоянно контролировать, не повис ли Master сервер 3) как из FDB переключать серверы из работы в резерв и наоборот, точнее подключая точку FBD программы я в списке объектов не вижу объектов резервного узла. т.е. я должен привязывать точку FBD-программы, к каналу "Системный" дополнение "Статус" основного узла, а система сама разберется какому узлу df или df(1) направить эти данные? 4) аналагичный вопрос по атрибуту "подключение" : имея резервный узел df(1) я в списке, который выдается при подключении точек FBD-программы к атрибутам каналов, не вижу объекта df(1)
отправлено / posted
1) В системе имеются специализированные каналы, которые позволяют реализовывать функции управления резервированием: СИСТЕМНЫЙ_Статус - в Input контролирует статус текущего узла. В Output - управляет статусом текущего узла. СИСТЕМНЫЙ_Приоритетный - в типе Input старший байт показывает статус удаленного (резервного) узла (2 - Мастер, 3 - Слейв). ДИАГНОСТИКА_Дубль - это счетчик, который начинает каждую секунду увеличивать свое значение, если по какой либо причине нет связи с удаленный узлом (оборвалась сеть или удаленный МРВ завис). Когда Вы разрабатываете дублированную систему, Вы создаете только один узел АРМ, другой (резервный) система создает автоматически за Вас. Все те алгоритмы и каналы, которые Вы создаете в основном узле, также создаются и в резервном. Но - когда Вы запускаете узлы под DF МРВ каждый из них я вляется индивидуальным узлом и хоть внутренняя база у них одинакова, но функционируют они каждый по своему. Поэтому в самих алгоритмах необходимо всегда опираться на статус текущего узла, чтобы выполнять какие-либо операции... Например, МРВ может переключиться в Мастер только если он до этого сам был Слейв и только, если произошла потеря связи с удаленным МРВ (контроль по каналу Диагностика_дубль).
Поэтому: "аналагичный вопрос по атрибуту "подключение" : имея резервный узел df(1) я в списке, который выдается при подключении точек FBD-программы к атрибутам каналов, не вижу объекта df(1)" - нельзя в качестве аргументов в математике привязаться к каналам резервного узла. Весь контроль за состоянием удаленного узла может осуществляться только через специализированные каналы. То, что Вы в АРМе привяжете выход FBD к каналу СИСТЕМНЫЙ_Статус с типом Output для управления статусом узла означает только то, что Вы будете управлять статусом текущего узла. Но - при этом система автоматически создаст ту же самую FBD, канал и выполнить такую же привязку к каналу и узле-дубле, а это означает, что запустив оба узла они будут функционаровать с одинаковой логикой, но каждый по-своему.
2) Сам статус узлов (Master\Slave) - это всего лишь управление включением/выключением определенного списка функций текущего сервера и ничего более. Эти функции также управляются через специализированные каналы: СИСТЕМНЫЙ_Ввод,Вывод и СИСТЕМНЫЙ_Сеть,DDE (подробности смотрите в справочной системе). Если МРВ в режиме Slave - это не значит, что он вообще не работает и вся его математика стоит, это означает только, что некоторый набор его функций отключен (например, рассылка по сети), но при этом вся его база продолжает пересчитываться и все его FBD также пересчитываются.
3) Если я буду решать задачу автоматического переключения серверов из резерва в работу и наоборот с помощью FBD программы, я должен создать FBD программу, выполняющую следуюшие действия : (1) постоянно следить за тем, есть ли связь с резервным сервером (2) постоянно контролировать, не повис ли Master сервер (3) переключать серверы из работы в резерв и наоборот (4) управлять атрибутом подключение каналов узла в резерве Так?
Все верно! Ведь Вы проектируете систему и Вы как проектировщик определяете какие группы каналов необходимо отключать от управления, когда узел находится в состоянии Slave. Например, если это каналы для управления задвижками - ведь это для Вас они каналы управления задвижками, а для системы - всего лишь каналы и ничего более, ни о каких задвижках она ничего не знает! Поэтому необходимо определить и сгруппировать эти функции (каналы, FBD и прочее), а также создать алгоритмы, по которым система будет управлять статусами этих каналов в зависимости от статуса текущего узла... Резервная система - это не просто дополнительный элемент, который функционально дублирует основной - это довольно сложный механиз управления приоритетами функций управления и контроля внутри каждого такого элемента, и если их не спроектировать и не реализовать, то Вы получите систему, в которой каждый МРВ будет "тянуть одеяло" управления на себя, а не поддерживать систему в балансе и осуществлять четкое и слаженное переключение как статусов узлов, так и их функций управления в нештатных ситуациях...
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Larik
Active Forum Member / Активный участник форума
Участник № / Member № 191
отправлено / posted
Здравствуйте. Мы сейчас отлаживаем DF МРВ и у нас возник ряд вопросов: 1.При переключении узла в резерв снял запрет запроса данных каналами СВЯЗЬ-IN NET с помощью канала СИСТЕМНЫЙ-Сеть,DDE. Связь идёт, но очень медленно, чем при состоянии узла РАБОТА. Приходится ждать очень долго, пока поменяется значение, которое генерируется третьим узлом. 2.Почитав форум я понял, что если нам ,например, не нужно синхронизировать значения каналов и СПАД, то всё преимущество DF сводится только к тому, что в нем работает канал ДИАГНОСТИКА-Dubl. Всё остальное можно сделать и в обычном МРВ? Каналы "СИСТЕМНЫЙ-Сеть,DDE" и "СИСТЕМНЫЙ-ввод,вывод" там тоже будут работать?
Сообщения / Posts 76 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1) Надо смотреть лог-файл - скорее всего не хватает NCB-блоков для обмена, отсюда и задержки. 2) Да, вполне возможно использование обычных МРВ, если не планируется синхронизировать СПАД, базы и осуществлять контроль дубля.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[clever / умный]](graemlins/clev.gif)
![[Улыбка / Smile]](smile.gif)
![[Неодобрение / Frown]](frown.gif)
