Здравствуйте! Наше предприятие приобрело Double Force. Возможен ли переход с обычного МРВ на Double Force без внесения в проект каких-либо изменений.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да - в самой структуре узла АРМ ничего при этом менять не нужно. Double Force МРВ это тот же самый МРВ, только с поддержкой некоторых функций горячего резерва на уровне узлов.
Posted by Dima (Участник № / Member № 839) on :
Попробовал перевести проект под Double Force (всё действия в соответствии с Руководством пользователя). В узел были добавлены каналы: 1)Канал типа Input подтип "Системный" дополнение "Статус" отображающий состояние сервера. 2)Аналогичный канал, но типа Output. 3)Канал подтипа ДИАГНОСТИКА с дополнением ДУБЛЬ 4) Канал подтипа СИСТЕМНЫЙ с дополнением ПРИОРИТЕТНЫЙ. Для всех каналов узлы были установлены флаги "В сеть". Затем был создан резервный узел. На первом сервере запускаю профайлер, Double Force и загружаю основной узел. Тоже самое на втором сервере, но узел Резервный. Показания каналов на первом сервере: 1)Состояние - работа 2)-"- 3)Нарастающее 16-тиричное число 4)Значение показывающее наличие партнера со статусом работа.
Показания каналов на втором сервере: 1)Состояние - работа 2)-"- 3)Нарастающее 16-тиричное число 4)Значение показывающее наличие партнера со статусом работа. При попытке на втором сервере установить его в "резерв" в резерв переводятся оба сервера и наоборот. То есть оба сервера или в работе или в резерве. Что я сделал неправильно и какие особенности не учёл?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Немного не понятна процедура "На первом сервере запускаю профайлер, Double Force и загружаю основной узел." - Вы грузите узлы в Профайлере Инструментальной системы или сервер запускаете из инструменталки, а консоль из Double Force МРВ?
Итак - немного об особенностях: 1) Между ПК должен быть доступ по сети как на файловом уровне, так и на уровне DCOM. 2) При запуске двух DF МРВ HASP-ключь должен быть от DF МРВ. Никакие больше ключи вроде инструментальной системы в ПК стоять не должны иначе при запуске МРВ не разрешит использовать функций DF МРВ, а запуститься как обычный МРВ. 3) На ПК с DF МРВ должно быть синхронизировано системное время. 4) В проекте у Вас должен быть хотябы один канал с автопосылкой в сеть (например, генератор пилы). Вроде все основные требования, но самое главное из них - это №2... Posted by Dima (Участник № / Member № 839) on :
Все 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?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Исходя из поставленой Вами задачи - создать два резервных узла и одно дополнительное рабочее место оператора в сети, которое будет подключаться к МРВ в режиме МАСТЕР, Вам не нужно было создавать в проекте еще один узел "arm". Консоль NetLinkLight при запуске должна подключаться к уже работающему серверу в режиме МАСТЕР, и брать его же графическую бызу для отображения.
2) Переход МРВ из режима ПОДЧИНЕННЫЙ в режим МАСТЕР при потере связи с МАСТЕРОМ не автоматический, Вы сами должны управлять им через канала подтипа СИСТЕМНЫЙ_Статус. А уж как Вы это будете делать - через графику вручную по кнопке или напишете FBD, которая будет делать это автоматически - решать Вам.
3) Переключение консоли NetLinkLight на следующий сервер при потери связи с текущим происходит только в том случае, если Вы задали список этих серверов и указали таймаут переключения в специальном INI-файле проекта. Подробности смотрите в справочной системе в разделе "Работа в реальном времени"-"Графическая консоль МРВ"-"Переключение между серверами".
Одна только странность, которая пока еще остается для меня загадкой - почему у Вас генератор пилы бежит с шагом 2?
Также напоминаю Вам, что приобретенные Вами продукты ТМ до сих пор Вами не зарегистрированы. Рекомендую Вам зарегистрировать их иначе Вы не сможете получать техническую поддержку!
Posted by Droshnev (Участник № / Member № 132) on :
В продолжение нашего телефонного разговора, особенно момента насчет переключения статуса(режима работы) узла, вот выдержка из файла помощи:"Анализ наличия резервного узла при работе в реальном времени для автоматического переключения статуса узла;" Как же тогда понимать фразу "для автоматического переключения статуса узла"??? Почему я должен использовать FBD-программу, когда речь идет об автоматическом переключении???
И все-таки повторю вопрос: ПОЧЕМУ УЗЕЛ НЕ ПЕРЕХОДИТ ИЗСОСТОЯНИЯ STS_TRACE В STS_WORK?
И почему узел, который находился в состоянии STS_WORK после обрыва связи не переходит в состояние STS_TRACE???
Жду ответа.
Posted by Droshnev (Участник № / Member № 132) on :
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 by AdAstra Technical Support (Участник № / Member № 4) on :
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 должны быть отключены (управлением атрибутом Подключение), а кроме того - в списке автопосылок они должны быть замкнуты сами на себя.
Posted by Dima (Участник № / Member № 839) on :
>"другие значения относительно основного сервера" - это можно объяснить тем, что для этого канала Вы не задали возможность синхронизации атрибутов по Мастеру. Синхронизируемые каналы в режиме 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 by AdAstra Technical Support (Участник № / Member № 4) on :
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 и прочее), а также создать алгоритмы, по которым система будет управлять статусами этих каналов в зависимости от статуса текущего узла... Резервная система - это не просто дополнительный элемент, который функционально дублирует основной - это довольно сложный механиз управления приоритетами функций управления и контроля внутри каждого такого элемента, и если их не спроектировать и не реализовать, то Вы получите систему, в которой каждый МРВ будет "тянуть одеяло" управления на себя, а не поддерживать систему в балансе и осуществлять четкое и слаженное переключение как статусов узлов, так и их функций управления в нештатных ситуациях...
Posted by Larik (Участник № / Member № 191) on :
Здравствуйте. Мы сейчас отлаживаем DF МРВ и у нас возник ряд вопросов: 1.При переключении узла в резерв снял запрет запроса данных каналами СВЯЗЬ-IN NET с помощью канала СИСТЕМНЫЙ-Сеть,DDE. Связь идёт, но очень медленно, чем при состоянии узла РАБОТА. Приходится ждать очень долго, пока поменяется значение, которое генерируется третьим узлом. 2.Почитав форум я понял, что если нам ,например, не нужно синхронизировать значения каналов и СПАД, то всё преимущество DF сводится только к тому, что в нем работает канал ДИАГНОСТИКА-Dubl. Всё остальное можно сделать и в обычном МРВ? Каналы "СИСТЕМНЫЙ-Сеть,DDE" и "СИСТЕМНЫЙ-ввод,вывод" там тоже будут работать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Надо смотреть лог-файл - скорее всего не хватает NCB-блоков для обмена, отсюда и задержки. 2) Да, вполне возможно использование обычных МРВ, если не планируется синхронизировать СПАД, базы и осуществлять контроль дубля.
![[clever / умный]](graemlins/clev.gif)
![[Улыбка / Smile]](smile.gif)
![[Неодобрение / Frown]](frown.gif)