Зарегистрирован: Jan 24, 2011 Сообщения: 53 Рейтинг: +0/-0
Добавлено: Чт 05 Май, 2011 5:47:45 Заголовок сообщения: Два модуля CNBR в корзине I/O
Имеем:
Две резервируемые корзины
В каждой по 2 модуля CNBR. Один для подключения Panel view, другой для включения в общую сеть (по двум каналам A и B).
Три корзины I/O
В каждой тоже по два CNBR модуля. Оба подключаются к общей сети (соответственно имеют разные адреса.)
Как мне объяснили, это сделано для резервирования модулей CNBR (Т.е. если что то случается с одним из модулей, то второй продолжает работать.)
Вопрос: правильный ли это вообще подход?
Да нечто подобное. Но как это должно выглядеть в RSLogix? Там ведь когда в сеть добавляешь CNBR модуль, он добавляется с новым шасси.
Будут ли модули в корзине I/O взаимозаменяемы (т.е. если один выйдет из строя, то ничего не будет?)?
Я немного физики не понимаю..
Зарегистрирован: May 27, 2010 Сообщения: 17 Рейтинг: +0/-0 Откуда: Пермский край г.Березники
Добавлено: Чт 05 Май, 2011 9:54:04 Заголовок сообщения:
Меняем модуль с той же прошивкой что и был и пусть работает дальше. При построении подобной сети, возможна даже перепланировка сети с добавлением новых модулей IO
''Да нечто подобное. Но как это должно выглядеть в RSLogix? Там ведь когда в сеть добавляешь CNBR модуль, он добавляется с новым шасси.''
При добавлении CNBR в корзину контроллеров вы потом связываете его с CNBR корзины IO, т.е. реально вы добавляете в проект 2 CNBR, я конечно не много не понял про адресацию в вашем проекте у нас сделано как на картинке.
А вы кто проектант или разработчик ПО
Зарегистрирован: Jan 24, 2011 Сообщения: 53 Рейтинг: +0/-0
Добавлено: Чт 05 Май, 2011 11:09:30 Заголовок сообщения:
Я разработчик ПО...в проекте вообще даже схемы нет...
Из проекта я понял, что выглядеть должно вот так
В резервируемых шасси адреса модулей cnbr - 44 и 46 соответственно
В IO-шасси 1,2...6 соответственно...такое вообще допускается?? Как реализовать в RSlogix???
Зарегистрирован: May 27, 2010 Сообщения: 17 Рейтинг: +0/-0 Откуда: Пермский край г.Березники
Добавлено: Пт 06 Май, 2011 4:51:30 Заголовок сообщения:
Можно и допускается в проекте контроллера у вас будет 1 модуль CNBR связанный с 6ю CNBR модулями IO с разными адресами и слотами 0 или 1, соответственно будет 6 корзин IO попарно повторяющихся, много вопросов возникнет в связи с дублированием информации и управлением модулями вывода.
Еще
SRM рекомендуют ставить в последние слоты корзины.
Перепланировка сети (при добавлении модулей IO) без перехода в режим программирования невозможна
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пт 06 Май, 2011 6:51:59 Заголовок сообщения:
Читайте документ 1756-UM523.
Адреса каждого из модулей 1756-CNBR в резервированной паре должны быть идентичны.
В каждой из половин резервированной пары процессоров должен работать один и тот же проект. Более того, проект грузиться только в один из контроллеров (тот, который будет включен первым и станет primary).
В адресном пространстве ControlNet лучше не допускать "дырок". Если адреса модулей 1756-CNBR в корзинах IO идут, например, от 01 до 06, то лучше, чтобы адрес 1756-CNBR в корзине с процессором, к которому приписаны эти IO, был 07.
Поскольку на втором 1756-CNBR висит только PanelView, его адрес может быть, в принципе, любым. Важно только, чтобы он (а) не совпадал с адресом PanelView и (б) чтобы эти модули в обеих корзинах имели один и тот же адрес. Обе PanelView, кстати, тоже должны иметь один и тот же адрес, т.к. в резервированной паре процессоров работают не 2 проекта, а один проект.
P.S.: Не знаю, что вы там проектируете, но модули 1757-SRM больше не поставляются и к применению во вновь проектируемых системах не рекомендуются. Вместо них поставляются 1756-RM. Соответственно, в резервированных системах нужно применять не 1756-CNBR, а 1756-CN2R, не 1756-ENBT, а 1756-EN2T и т п. По этому поводу читайте 1756-UM535 и 1756-RN684 - RTFM. _________________ Обращайтесь к профессионалам.
Зарегистрирован: Jan 24, 2011 Сообщения: 53 Рейтинг: +0/-0
Добавлено: Пт 06 Май, 2011 8:04:19 Заголовок сообщения:
OldDad
Да вы правы - модули 1756-RM, но остальные это CNBR и ENBT. По этому поводу я звонил в техподдержку АБ. Мне сказали, что такая конфигурация пойдет. К тому же из собственного опыта: Прошивка 16.57 ControlLogix Standart Redundancy как раз поддерживает 1756-RM и 1756-CNBR и 1756-ENBT.
А как в RSlogix создавать конфигурацию контроллера? Меня волнует вопрос того, что:
Цитата:
Можно и допускается в проекте контроллера у вас будет 1 модуль CNBR связанный с 6ю CNBR модулями IO с разными адресами и слотами 0 или 1, соответственно будет 6 корзин IO попарно повторяющихся, много вопросов возникнет в связи с дублированием информации и управлением модулями вывода.
Зарегистрирован: May 27, 2010 Сообщения: 17 Рейтинг: +0/-0 Откуда: Пермский край г.Березники
Добавлено: Пт 06 Май, 2011 8:12:59 Заголовок сообщения:
Создаете стандартный резервированный проект, в него добавляете модуль CNBR (в последствии в настройках модуля будет привязка к файлу NetWorx for ControlNet) далее от этого модуля создаете 6 модулей связи с корзинами IO, могу конечно вам прислать и готовый проект если не понятно.
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пт 06 Май, 2011 11:09:39 Заголовок сообщения:
Aleksky писал(а):
Прошивка 16.57 ControlLogix Standart Redundancy как раз поддерживает 1756-RM и 1756-CNBR и 1756-ENBT.
Да, это так. Но подумайте о том, что:
- Вы пишете о 1757-SRM, а они уже не поставляются (и это есть железный факт).
- Прошивка 16.57 - это промежуточный паллиативный вариант, применяемый вынужденно и только для тех случаев, когда в уже имеющейся системе отказал 1757-SRM, его пришлось заменить на 1756-RM, и в итоге возникает ситуация, когда не подходит ни старая имеющаяся прошивка (она не знает 1756-RM), ни более новая (она не знает ни 1756-CNBR, ни 1756-ENBT).
- Для новых систем производитель не рекомендует старьё, которое уже не поставляется, и поэтому будут вынужденно применяться устаревшая, не обеспечивающая всех возможностей прошивка. Рекомендуется применять а 1756-RM, 1756-CN2R, 1756-EN2T и т п. под прошивкой v19.52.
- Если Вы, проектируя новую систему, примените старую прошивку и старое железо в новой системе, то таким образом подставите пользователя, т.к. система в таком виде не будет иметь будущего.
Применять старое железо только потому, что разработчики не знают нового, по-моему, хм, как это помягче сказать, не очень целесообразно. Надеюсь, Вы понимаете, что я хотел сказать.
Впрочем, это дело ваше. Хотите поиметь проблемы, а потом их мужественно превозмогать? Нет проблем. _________________ Обращайтесь к профессионалам.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
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.139 секунды