Просмотр полной версии : Слетают данные из Slave ПЛК 110 М02
Приветствую!
Стала появляться проблема на ПЛК110 на 2х объектах. (тепловые пункты котельных). Есть ПЛК110, верхний уровень Scada система через OPC сервер ОВЕН. По какой то причине данные (уставки) заданные через SCADA слетают в 0. Проявляется не регулярно. Связь ПЛК с SCADA - Modbus TCP. В ПЛК, slave сделан через стандартный конфигуратор. ПЛК на 24v. Блоки питания запитаны через ИБП. В чем проблема?
Евгений Багаев
24.04.2019, 12:11
Приветствую!
Стала появляться проблема на ПЛК110 на 2х объектах. (тепловые пункты котельных). Есть ПЛК110, верхний уровень Scada система через OPC сервер ОВЕН. По какой то причине данные (уставки) заданные через SCADA слетают в 0. Проявляется не регулярно. Связь ПЛК с SCADA - Modbus TCP. В ПЛК, slave сделан через стандартный конфигуратор. ПЛК на 24v. Блоки питания запитаны через ИБП. В чем проблема?
Здравствуйте.
Обновите прошивку до v1.0.5. Либо на v1.0.4 вручную активируйте режим записи по событию командой в ПЛК-браузере SetCyclicMode 0.
Руководство по работе с Retain-переменными (https://www.owen.ru/uploads/149/rukovodstvo_po_rabote_s_retain_peremennymi_plk110_ 160_v1.1.pdf)
Скачать и посмотреть историю изменений ПО ПЛК110 [М02] (https://www.owen.ru/forum/showthread.php?t=31023)
Здравствуйте.
Обновите прошивку до v1.0.5. Либо на v1.0.4 вручную активируйте режим записи по событию командой в ПЛК-браузере SetCyclicMode 0.
Руководство по работе с Retain-переменными (https://www.owen.ru/uploads/149/rukovodstvo_po_rabote_s_retain_peremennymi_plk110_ 160_v1.1.pdf)
Скачать и посмотреть историю изменений ПО ПЛК110 [М02] (https://www.owen.ru/forum/showthread.php?t=31023)
Я знаю про ситуацию когда ПЛК после презагрузки по питанию терял данные. В моем случае с питанием все в норме. Либо все равно это и есть тот баг?
Евгений Багаев
24.04.2019, 14:21
Бегло прочитал название темы, думал речь идет про Retain. Здесь что-то другое. После каких событий стало проявляться такое поведение? Сколько отработали до проявления? Что-то менялось в конфигурации: аппаратные или программные компоненты?
Бегло прочитал название темы, думал речь идет про Retain. Здесь что-то другое. После каких событий стало проявляться такое поведение? Сколько отработали до проявления? Что-то менялось в конфигурации: аппаратные или программные компоненты?
Два объекта со SCADA запущены в январе 2019. На одном объекте данный баг произошел уже 2 раза за этот период. На втором объекте произошел первый раз сегодня
В конфигурации ни чего не менялось. В чем причина понять не могу. Все электропитание через бесперебойники
Проект можно посмотреть по ссылке https://yadi.sk/d/lty4vgG-zSVs7g
В верхнем уровне
На кого грешить? На OPC Овен или Scada SimpLight?
Любой из них кто может инициировать запись в ПЛК.
Лучше думать о том как от это защитится.
Есть мысли как обезопасить? Может подскажете что.
Есть мысли как обезопасить? Может подскажете что.
не плохо бы для начала, чтоб сохранили лог запросов ответов в момент когда обнуляются переменные, чтоб именно эту версию отрабатывать
Разговаривал с представителем Scada SimpLight они уверенно говорят, что система не может самостоятельно записать значения без действий оператора, тем более по всем каналам. Говорят копайте OPC. На ПЛК я тоже не грешу если честно. Много систем где панель таже СП300 мастером для ПЛК110 по Modbus TCP и там все ОК.
не плохо бы для начала, чтоб сохранили лог запросов ответов в момент когда обнуляются переменные, чтоб именно эту версию отрабатывать
LOG файл OPC OWEN по ссылке https://yadi.sk/d/4Yk1rgkVMyT_Tw
Посмотрел логи скады, там ничего, записи с 9-00 это когда уже начали вводить обнуленные значения.
По логам OPC можете подсказать? Есть там криминал?)) Случилось все сегодня рано утром
Говорит технарь или продаван ?
Говорят или приложил четкий алгоритм поведения при не получении ответа на транзакцию записи за заданное время ?
Бабки у подъезда тоже много чего говорят.
И это может быть. По отношению к ПЛК это такой верхний уровень.
Не был бы столь категоричен, но вероятность существенно ниже
Разговаривал с Тех поддержкой. Они предложили посмотреть логи скады. там все чисто. Вот логи OPC я выложил выше. Рад буду помощи в их проверке.
2019-04-24 04:56:47.1355 TRACE 24-04-2019 04:56:47.134 : Устройство вернуло ошибку. Тепловой пункт (ПЛК110-60).ПЛК.HMI_P_vihod_otoplenie2 (Код: 10 - Вычисленное значение слишком велико) device: Тепловой пункт (ПЛК110-60).ПЛК port: Rx Rx, size: 0, data:[]
например можно с этой записи начать, это на вскидку, вечером посмотрю еще
например можно с этой записи начать, это на вскидку, вечером посмотрю еще
Я видел эту запись. Так и не понял что это значит. Если бы опрашивался модуль аналогового ввода напрямую, тогда можно было бы подумать что показания датчика вне диапазона.
Поводив ползунком , начало таких записей где-то с 4:22 и как показалось именно после этого начали в ответах возвращаться нули, наверное все же со слейвом проблемы, он мусор послал вот и не был распознан ответ
Если всетаки slave плк. Как далее быть? Может представители ОВЕН ответят. А то мне скоро надо еще 4 тепловых пункта на котельных делать. Как с такими багами жить? Обратной связи от техподдержки ОВЕН сегодня так и не дождался.
Лично у меня духу не хватит 200м листать
А причем тут модуль аи и опс ? Как они контактируют ?
Ну послал кто мусор, и что случится такого страшного дальше ?
В том то и дело что опс и аи модуль никак не контактируют. А ошибка по описанию как будто показания датчика вне диапазона. Непонятная вобщем ошибка.
Откуда тогда на опс данные датчиков ?
Модули аи опрашивает плк по rs485. Опс опрашивает только плк.
2019-04-24 09:46:14.7791 TRACE 24-04-2019 09:46:14.786 : device: Тепловой пункт (ПЛК110-60).ПЛК port: Rx Rx, size: 113, data:[65 2E 00 00 00 6B 01 03 68 00 00 42 34 00 00 42 BE 00 00 43 48 00 00 3F 00 00 00 43 96 00 00 00 00 00 00 3F 00 00 00 40 00 00 00 41 20 00 00 41 70 00 00 43 96 00 00 41 00 00 00 C2 00 00 00 42 70 00 00 42 BE 00 00 3F 00 00 00 43 0C 00 00 00 00 00 00 3F 80 00 00 3F 80 00 00 40 40 00 00 41 70 00 00 43 48 00 00 42 74 00 00 42 34 00 00 42 70 ]
2019-04-24 09:46:15.7517 TRACE 24-04-2019 09:46:15.751 : device: Тепловой пункт (ПЛК110-60).ПЛК port: Tx Tx, size: 12, data:[65 2F 00 00 00 06 01 03 00 00 00 7C ]
2019-04-24 09:46:17.3074 TRACE 24-04-2019 09:46:17.306 : Нет ответа от устройства device: Тепловой пункт (ПЛК110-60).ПЛК port: Rx Rx, size: 0, data:[]
вроде как здесь уже явное отсутствие ответа от слейва
HMI_P_vihod_otoplenie2 по какому адресу находится эта переменная?
Ну не ответил девайс, и что делает мастер/клиент ? . Я ж спрашивал.
но это 9 утра может там уже перезапускали плк, потому что ни чего не работает из-за отсутствия настроек
Еще бы знать какие регистры смотреть в какое время именно они обнулились
В 9 утра уже начали вводить данные заново. Мне сообщили часов 11. Адрес переменной могу завтра уже посмотреть, сейчас проект не на чем открыть. Ну или проект выше по ссылке))
HMI_ustavka_T_grafik_otopl2 может иметь значение 63.6 градусов?
HMI_ustavka_T_grafik_otopl2 может иметь значение 63.6 градусов?
Да это расчетная уставка температуры по графику. Выводится для информации в скаду
у неё какое то не фиксированное значение она постоянно меняется почему то, а вот пропорциональная и интегральная (регистры 166 и 168) так до 9:40 и не сбрасывались в ноль, 166 регистр постоянно равен 15
у неё какое то не фиксированное значение она постоянно меняется почему то, а вот пропорциональная и интегральная (регистры 166 и 168) так до 9:40 и не сбрасывались в ноль, 166 регистр постоянно равен 15
Все верно. Она постоянно меняется в зависимости от температуры наружного воздуха.
Интегральные и пропорциональные визуально в скаде были сброшены в ноль. Пид не работал. Отопление сильно просело. Около 13 часов я вводил параметры пид. по двум контурам отопления и и контуру гвс. Все было в 0.
Пообщался с коллегой он говорит что на втором объекте где такая же ситуация возникала 2 раза вроде всетаки сам плк виноват. Там плк управляет еще тремя частотниками Vacon. Когда к частотникам нет запроса от мастера они инициализируют ошибку по связи и выдают информацию на свои панельки. Дак там объект падает в таком виде - в скаде также все уходит в 0 и еще к тому же плк по rs 485 прекращает опрос частотников. Как то так.
тогда я не знаю в чем дело, по логам в 14:08:59.5593 интегральную со значения 200 поменяли на значение 250, ни о каких нулях приходящих в ответах от плк лог ничего незнает, вот как было до этого времени с начала файла так и стоит 200
тогда я не знаю в чем дело, по логам в 14:08:59.5593 интегральную со значения 200 поменяли на значение 250, ни о каких нулях приходящих в ответах от плк лог ничего незнает, вот как было до этого времени с начала файла так и стоит 200
Тоесть интегральная с ночи 24.04.19 стоит 200? Ниче не понимаю. Где то в 13-14 часов я вводил значения. Настройки пид по всем трем контурам в скаде были нулевые. Клапана не работали. Как только я выставил значения коапана зашевелились.
на предыдущих версиях плк, модбас работает даже если программа находится в стопе, может в этой ситуации тоже как то с этим связано, когда в девять пропадала связь это была перегрузка плк или просто шнур кто то выдергивал для проверки
на предыдущих версиях плк, модбас работает даже если программа находится в стопе, может в этой ситуации тоже как то с этим связано, когда в девять пропадала связь это была перегрузка плк или просто шнур кто то выдергивал для проверки
Кто и что там выдергивал этого я не могу сказать. Объект от меня в 700 км. Вот есть еще мысль. На этих объектах шнур от плк идет в комутатор свитч, со свитча уже в комп. Свитчи не питаются от бесперебойников, как помню. Может провал какой по электричеству. Не понимаю вобще что творится. 2 объекта, одинаковые проблемы. Именно там где есть скада. Есть объект без скады но с панелю сп300. Связь также через ethernet. Никаких багов. Может ичключить опс и поднять опрос напрямую с скады? Там драйвер вроде есть для опроса.
Меня больше убивает что приходится уделять столько времени таким проблемам которых быть не должно. Представители ОВЕН так и не прокоментировали, может конечно и откликнутся еще. Файл это хорошо. Но я не работал с этим, надо время чтоб разбираться, а времени нет. На разработку программы бывает уходит куча времени для того чтоб добится нормальных показателей процесса, а в итоге тебя подставляет долбанный slave. Вот потом и приходится бежать за семеном. Хотя там тоже своих проблем хватает.
Меня больше убивает что приходится уделять столько времени таким проблемам которых быть не должно. Представители ОВЕН так и не прокоментировали, может конечно и откликнутся еще. Файл это хорошо. Но я не работал с этим, надо время чтоб разбираться, а времени нет. На разработку программы бывает уходит куча времени для того чтоб добится нормальных показателей процесса, а в итоге тебя подставляет долбанный slave. Вот потом и приходится бежать за семеном. Хотя там тоже своих проблем хватает.
так почему слейв то, он не отвечал там всего несколько секунд, данные как я понял исправно доходили до ОРС, в скаде не отображались, пускай даже еслиб это были фиктивные значения, в ответах они были и должны были появиться на визуализации. ОРС может поддерживать ведь несколько соединений, запустите еще какое нибудь приложение которое будет читать ОРС и если опять станут утверждать что на экранах нули останется только свериться с паралельным архивовм данных
ТС утверждает что что-то поменял с нулями и пошла движуха.
=> значит была связь
=>
if плк = 0 then
к овену : какого хрена ?
else
к скаде/опсу : какого хрена на экране 0 если на плк не 0 ?
end_if
В 13-14 часов 24.04.19 я подключился к скаде через тим вивер. Настройки всех регуляторов в полях ввода стояли значения 0. Регуляторы тоже не работали. Клапаны не шевелились. Я ввел значения и все пошло поехало))). Надо было мне посмотреть в самом опс а лучше заглянуть в плк.
В 13-14 часов 24.04.19 я подключился к скаде через тим вивер. Настройки всех регуляторов в полях ввода стояли значения 0. Регуляторы тоже не работали. Клапаны не шевелились. Я ввел значения и все пошло поехало))). Надо было мне посмотреть в самом опс а лучше заглянуть в плк.
Вы что настройки ПИД-регуляторов постоянно меняете ? Настройки ПИД-регуляторов и прочего критично важного надо забить в ПЛК и спать спокойно.
Вы что настройки ПИД-регуляторов постоянно меняете ? Настройки ПИД-регуляторов и прочего критично важного надо забить в ПЛК и спать спокойно.
В данном случае требование заказчика чтобы все настройки регуляторов были выведены на скаду. И всего остального.
Дело не в том что выведено и не выведено, а в том какого лешего все слетает. Битовые переменные тоже были установлены в 0.
Нашел еще проблему OPC Овен при взаимодействии с сервисом OwenCloud.
OPC не пишет данные типа float в клауд а затем в ПЛК. Пишет только целые числа.
Версия OPC последняя
https://youtu.be/MZddAQUFHzM
В общем причину я установил! Плк был сброшен по сторожевому таймеру. Запись в debug.txt - PLC was reset by watchdog
Неужели для него это большая сетевая нагрузка?
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot