Re: DIGSI и терминалы SIPROTEC
можно, в матрице ранжирования специальный столбец, где можно ставить либо удалять галочки для регистрации сигналов в осциллограммах.
Нет там такого.
Нужно изменять свойства каждого сообщения по правой кнопке мыши.
Форум посвящен вопросам релейной защиты и автоматики (РЗА). Обмену опытом и общению релейщиков. |
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Если вы интересуетесь релейной защитой и реле, то подписывайтесь на мой канал
Советы бывалого релейщика → Програмное обеспечение МП устройств релейной защиты → DIGSI и терминалы SIPROTEC
можно, в матрице ранжирования специальный столбец, где можно ставить либо удалять галочки для регистрации сигналов в осциллограммах.
Нет там такого.
Нужно изменять свойства каждого сообщения по правой кнопке мыши.
Нужно изменять свойства каждого сообщения по правой кнопке мыши.
спасиб, то что надо.
Нужно изменять свойства каждого сообщения по правой кнопке мыши.
ну да, точно. Давно с сименсами работал. Да, надо каждое сообщение правой клавишей мышки кликать и ставить галку "писать в осциллограмму".
Столбцы - это непосредственно в осциллограмме. Там можно выводить только нужные сигналы в осциллограме из всех доступных.
Может, у кого-то еще осталась такая древность, как DIGSI 4.6 или 4.7? Поделитесь, пожалуйста!
Имеется даже 4.0 :-) и практически все последующие версии.
Но закачать через Нет-а целое DVD ...
Присоединяйтесь!!! Мы в социальных сетях и на Ютуб. |
объясните как обновить digsi 4.85 до последней версии?? обновление скачал , но не получается поставить)
Подскажите, пожалуйста, кто знает что исправляют последние прошивки 7SA522 v 04.73.03 и 7SS522 V4.73. Может быть исправления не критичны и не стоит прошивать терминалы?
Подскажите, пожалуйста, кто знает что исправляют последние прошивки 7SA522 v 04.73.03 и 7SS522 V4.73. Может быть исправления не критичны и не стоит прошивать терминалы?
Вообще, прошивать стоит. Потому как новые прошивки и появляются после исправления ошибок. Существенные они или нет? Это как посмотреть. Что до конкретных исправлений должно быть где-то обозначено. Покопайтесь на сайте Сименса.
Однако если у вас обслуживания планового в ближайшем времени не предвидится - не заморачивайтесь. Прошивать на мой взгляд стоит при очередной плановой проверке.
Да и коллега Конспиратор так и советует. А вообще мы никогда не перепрошивали. Пока однажды не столкнулись что на некоторых прошивках 7СА522 работает некорректно. Там спешно перепрошивали. На некоторых подстанциях терминалы по 10лет стоят со старой прошивкой и ничего. Ни один нормативный документ насколько я знаю не регламентирует обновление прошивки.
Вы видели информационные письма? Я видел Инф. письмо ЭКРА, но после него плакать хочется.
У нас в релейке много вопросов конкретных к нашим местным терминалам белорусского производства. Вопросы в основном мелкие. Но они есть. То уставки неправильно переключаются, то осциллограммы некорректно отображаются, то еще что-то. Благо есть дружеские отношения с разработчиками. Они с большим энтузиазмом идут на контакт, многие некорректности устраняют. У них новые прошивки довольно часто появляются. Но это больше относится к новым устройствам. Старые как есть остаются.
А про письма информационные - плакать на самом деле хочется.
Увидели письма после ложного отключения 7SA522 v4.61. Спросить в Беларуси про терминалы Siemens не у кого. Покупаем терминалы через фирмы, где работают одни менеджера.
Подскажите, пожалуйста, кто знает что исправляют последние прошивки 7SA522 v 04.73.03 и 7SS522 V4.73. Может быть исправления не критичны и не стоит прошивать терминалы?
К прошивке ДЗШ нужно подходить с осторожностью.... Надо смотреть совместимость периферийных блоков с новой прошивкой....
У ДЗ новая прошивка сделана для выполнения требования ФСК, чтобы чувствительность по току у FFM (стала равной 0,05 от номинала вместо 0,1) была не менее, чем у ДЗ. Плюс в симметричном алгоритме FFM исключена возможность отказа при несимметричных токах нагрузки, близких к порогу чувствительности (опять же по требованию ФСК).
По вопросу несовпадения версий PSV и разнообразия версий/языков ПО DIGSI при подключении к контроллерам Сипротек. Аналогичная ситуация произошла на п/ст N, после того, как к блокам РЗиА типа Сипротек несколько раз подключались представители подрядных организаций, начиная от АСУТП и заканчивая службами аудита, с родного программатора (с которого выполнялись все параметризации оборудования) не получилось подключиться к некоторым приборам. Описание стычек с руководством по вопросам виновности опускаю. Но выход подсказали, и он оказался весьма нетривиальным. На работающем блоке контроллера снимается передняя панель и на пару секунд вынимается батарейка энергонезависимой памяти. Главное предупредить системщиков SCADA (если у Вас такая существует) о приближающейся катастрофе (серия алармов по состоянию питания 5 В). И мы спокойно подключились своим программатором.
Встречный вопрос знатокам. Не встречалась ли такая ситуация, когда после обновления PSV останавливалась функция счётчика энергии на контроллерах 7SJ622 (или им аналогичные)? Все параметры остались без изменения, SCADA по своим каналам данные получает, а внутренний отсчёт значений обнулился и не запускается
Увидели письма после ложного отключения 7SA522 v4.61. Спросить в Беларуси про терминалы Siemens не у кого.
А что за вопросы? Вообще мы с такой проблемой столкнулись года 2 назад. Что-то сами додумывали. О чем-то у коллеги Конспиратора спрашивали. Людей, разбирающихся с Сименсами, в Беларуси не так уж мало. Надо только знать у кого спрашивать.
Другое дело, что у официальных представителей специалистов не хватает. Хотя и там тоже кое в чем помогали.
Здравствуйте! Надеюсь, я по адресу. Сейчас идет К1 РЗА КВЛ-110 на 7SA522. Версия прошивки 4.72.
Столкнулся с такой проблемой. Для переключения между режимами АПВ из СКЗУ и с кнопки терминала (была свободна только одна). Присутствует цепочка - счетчик (c обратной связью от OVERFLOW на RESET для сброса)- преобразователь типа DINT_TO_REAL - компаратор COMPARE - импульсный таймер - и далее по логике. Все в приоритете MW_BEARB. Сразу после инициализации все прекрасно работает. После перезагрузки именно эта цепочка - отказывает. Таймеры аналогичные есть в других цепочках, работают.
Вспоминается аналогия из старых прошивок о "зависании таймеров" при перезагрузке, которая лечилась сбросом от сигнала внутренней неисправности (не застал, могу ошибаться). Есть идея попробовать позаводить этот сигнал на сбросы счетчика или еще куда. Возможно, кто-то сталкивался с этим или просто имеет какие мысли?
(c обратной связью от OVERFLOW на RESET для сброса)
Обратные связи, как я помню, могут всё портить. Там, как я помню, специальный элемент надо использовать "обратная связь".
Ну и обязательно нажимать кнопочку "оптимизация" перед компиляцией CFC.
Обратные связи, как я помню, могут всё портить. Там, как я помню, специальный элемент надо использовать "обратная связь".
Ну и обязательно нажимать кнопочку "оптимизация" перед компиляцией CFC.
1. Напомню, все испортилось только после перезагрузки, до этого работало.
2. Оптимизация - это оптимизация последовательности выполнения? Если да, то пользуем.
3. Насчет блока LOOP - обратная связь. Смущает в мануале
Примечание:
Чтобы избежать бесконечной обратной связи, сигнал не может быть
возвращен блоком LOOP более5 раз(входD=выходQ). Если это
количество превышено, на выходе LErr формируется сигнал
ошибки и обратная связь прерывается.
Я попробую, но это что, только 5 раз отработает цепочка? А зачем такая связь?
1. Напомню, все испортилось только после перезагрузки, до этого работало.
Да, после перезагрузки происходит инициализации CFC логики, для этого не должно быть противоречий в начальных условиях, а с обратными связями это возможно.
Что касается LOOP - видимо речь идёт о максимум пяти циклах возврата внутри одного цикла инициализации, дабы избежать "подвисания" при некорректно организованной обратной связи.
Оптимизация - это оптимизация последовательности выполнения? Если да, то пользуем.
Да,там, судя по некоторым наблюдениям, много чего оптимизируется. Действительно, лучше не забывать.
И последнее. Вспоминаю, что все аналоговые СFC блоки (компараторы например) должны быть все отдельно, со своим соответствующим типом, при этом связь между аналоговой частью CFC и дискретной осуществляется только через матрицу ранжирования.
Ошибся, у меня 4.71 прошивка.
Что касается LOOP - видимо речь идёт о максимум пяти циклах возврата внутри одного цикла инициализации, дабы избежать "подвисания" при некорректно организованной обратной связи.
LOOP поставил. Вроде как более пяти циклов допускает - пробовал жать-жать кнопку до сброса счетчика более пяти раз.
И последнее. Вспоминаю, что все аналоговые СFC блоки (компараторы например) должны быть все отдельно, со своим соответствующим типом, при этом связь между аналоговой частью CFC и дискретной осуществляется только через матрицу ранжирования.
Учту, но переделывать пока не буду уже. Дело было в другой бобине - логика формирования сигналов PulseON и PulseOFF от кнопок (я так понимаю, она стандартная) использовала таймеры, которые зависали. Лечил ANDами с DeviceOK на входе в таймер.
Хотя в логике обработки уже сигналов кнопок такого не было, таймеры не зависают. Тип таймеров и тип их логики - тот же. Сижу, думаю, подпирать их тоже ANDами, или не стоит? От чего вообще зависит, какие таймеры виснут, а какие нет?
От чего вообще зависит, какие таймеры виснут, а какие нет?
Всего, насколько я помню, есть два типа таймеров: "длинный" и "универсальный".
Обычно везде используется универсальный, который, в зависимости от используемых входов-выходов - может выполнять разные функции.
Но здесь всё дело в инициализации. DeviceOK формируется как раз после первой инициализации логики. Таким образом таймер "запускается", если его входной сигнал объединить по "И" с DeviceOK, уже когда всё "устаканилось" - что исключает возможные логические коллизии.
Всего, насколько я помню, есть два типа таймеров: "длинный" и "универсальный".
Обычно везде используется универсальный, который, в зависимости от используемых входов-выходов - может выполнять разные функции.
Таймер использовал универсальный (не Short и не Long).
Но здесь всё дело в инициализации. DeviceOK формируется как раз после первой инициализации логики. Таким образом таймер "запускается", если его входной сигнал объединить по "И" с DeviceOK, уже когда всё "устаканилось" - что исключает возможные логические коллизии.
Виноват, но проблемы возникают после первой перезагрузки. Сразу после инициализации все нормально.
Кстати, проблема с зависшим таймером обнаружена на вкладке "Keys F1-F4". Насколько я понимаю, она стандартная, и с такой проблемой должны столкнуться все, кто использует сигналы вида F1 PulseOn и F1 PulseOff.
Советы бывалого релейщика → Програмное обеспечение МП устройств релейной защиты → DIGSI и терминалы SIPROTEC
Форум работает на PunBB, при поддержке Informer Technologies, Inc