Просмотр полной версии : "мигает" МДВВ
Добрый день
имеется такая конфигурация (управляет в доме освещением)
ПЛК100 + 3хМДВВ + МВУ8 + МК100-8Р + МК110-8д-4р
Все соединено по modbus-rtu. Все работает на ура, кроме ОДНОГО из МДВВ - периодически мигают все источники освещения, подключенные на его реле. Остальные модули работают без проблем.
В чем может быть причина?
Да, и еще вопрос - индикаторы связи rs485 мигают с перерывами (частота опроса 25 мсек) - то есть мигают часто-часто секунд 10, потом пауза на полсекунды примерно, потом снова начинаю часто мигать. Это происходит на всех модулях. Кодесис на контроллере вроде ошибок не показывает (или просто не успевает?). Но это вобщем-то мелочи. Главный вопрос - почему мигает МДВВ
Заранее благодарен
Кирилл Валюнин
30.11.2011, 19:39
Подаете ШИМ на выходы модуля? Два других МДВВ себя так не ведут?
Все-таки проверил бы настройки обмена именно с этим модулем в проекте.
Верно ли выставлен адрес, нет ли дублирующих адресов.
Главный вопрос - почему мигает МДВВ
У меня было что-то похожее. Оказалось в программе выходную переменную из ПЛК-конфигурации обнулял, а затем присваивал нужное значение. Так вот данные на внешний модуль по RS485 передаются не по оканчанию цикла ПЛК, а по мере надобности!!! Как время пришло так данные берутся из программы и передаются по RS485, вне зависимости от того промежуточные эти данные или цикл программы окончен. Избавился от этого отказавшись от обнуления выходной переменной в программе и присваивал ей только заведомо верное значение.
Есть еще один вариант аналогичного поведения МДВВ - в ПЛК-конфигурации есть еще одна переменная, которая передается в адрес МДВВ и вот эта запись и выключает выхода МДВВ.
P. S. Выложи программу и люди обязательно помогут.
lara197a
30.11.2011, 19:48
Ну и 25мс маловато, при наличии нескольких устройств в сети.
Ещё посмотрите время цикла ПЛК. Тоже может чуть увеличить стоит. Я бы с времени цикла начал.
Поскольку от документации толку ноль, пришлось прочесать сей форум.
Что сделано - для модулей ввода/вывода установлен метод опроса "both" (polling+value change) и время опроса 100 мс. Для модулей вывода установлен метод опроса "by value change" и время опроса 200 мс.
Теперь все работает стабильно
У меня было что-то похожее. Оказалось в программе выходную переменную из ПЛК-конфигурации обнулял, а затем присваивал нужное значение. Так вот данные на внешний модуль по RS485 передаются не по оканчанию цикла ПЛК, а по мере надобности!!! Как время пришло так данные берутся из программы и передаются по RS485, вне зависимости от того промежуточные эти данные или цикл программы окончен. Избавился от этого отказавшись от обнуления выходной переменной в программе и присваивал ей только заведомо верное значение.
+1
та же пичалька... ПЛК150+2хМВУ8+1хМВА8 протокол ОВЕН - моргают оба МВУ.
я плакаю - такая ровная и красивая программка получилась, основанная на постоянном обнулении параметров в начале цикла и последовательной проверке условий для установки единички, при необходимости... и оно бы работало, если бы данные во внешние приборы передавались в конце цикла, а не постоянно...
Придется переписывать :``о((( А какую методу Вы применили взамен?
вместо конструкции:
a:=0; if условие1 then a:=1;... ; if условиеN then a:=1; (* честно так очень красивый и понятный код с учетом громоздких многоэтажных условий *)
или же конструкции:
case of
условие1: а:=1;
...
условиеN: a:=1;
else a:=0; (* что равносильно предыдущей*)
применить конструкцию:
if ИЛИ-ИЛИ-ИЛИ-ИЛИ, then а:=1, else a:=0?... Опять же не факт, что данные не передадутся посередине вычисления ЭТОГО условия, которое займет во времени 3-4 мс...
Я знаю, в этом и состоит икусство программирования - найти такой метод вычислений и проверки условий, который может выполнить оборудование, а не подгонять оборудование под свои фантазии, но...
!!! я ж ни_одного_бита не профессиональный программист, хелп!!! я только учус!
Может как-то можно принудительно заставить ПЛК не передавать данные на модули до окончания цикла, а передавать их в периоды простоя - от завершения программного цикла до времени ПЛК-цикла. Мне лично можно и 50 мс ПЛК-цикл сделать при 10 мс программном цикле...
Я вот видел в ПЛК-конфигурации в описании связи RS-485 бит "Старт/стоп"... может можно как-то принудительно управлять посылками на модули? например, заблокировать посылку инфы в период действия цикла (в начале программного цикла прописать - СТОП RS-485, в конце цикла прописать СТАРТ RS-485)... тогда эти 10 мс, пока отрабатывает программа - данные не передаются, а потом оставшиеся 40 мс - пусть передаются в любом количестве!!! ибо это будет как раз необходимый, проверенный по всем условиям, параметр...
КАК управлять работой связи RS-485??????????????
Хелп, плииииз!!!
2 lara197a: так же, подумал, что время ПЛК-цикла меньше времени цикла программы... приехал на объект - щас всё порешаю, одним пальцем! :о((( Ы-ы...
поставил 50 мс, и та же свистопляска хотя статистика показывает - "свободных 40мс". НО! свистопляска стала явно жиже... от увеличения ПЛК-цикла явно снижается частота "миганий". Я полагаю это логичным, если принять, что данные передаются "by polling time (100мс)" вне зависимости от конца цикла - просто сами единички и нули в одном параметре сменят друг друга гораздо реже.
И кстати, метод опроса "by value change" в моем случае не прокатит - данные обнуляются и объединиваются (т.е меняются) в каждом цикле - опять будет то же самое...
p.s. а еще довольно редко, но постоянно выскакивает ошибка связи 81... все в одном щите, бок к боку на дин-рейке, связь-витая пара, резисторов оконечных нет.
чтобы не "плакать", надо взглянуть шире на вашу "проблему" с передачей, а не зацикливаться на "красивости кода"
делайте ваши вычисления в программе любым удобным способом
a:=0; if условие1 then a:=1;... ; if условиеN then a:=1; (* честно так очень красивый и понятный код с учетом громоздких многоэтажных условий *)
можете хоть 5000 раз за цикл поменять значение этой переменой, но в plc_prg делайте присвоение
perem_to_rs485 := a;
раз в цикл
и эту perem_to_rs485 заводите на передачу в устройства
чтобы не "плакать", надо взглянуть шире на вашу "проблему" с передачей, а не зацикливаться на "красивости кода"
делайте ваши вычисления в программе любым удобным способом
можете хоть 5000 раз за цикл поменять значение этой переменой, но в plc_prg делайте присвоение
perem_to_rs485 := a;
раз в цикл
и эту perem_to_rs485 заводите на передачу в устройства
гениально! снимаю шляпу...
было задумался в эту сторону, но увела меня пичалька от позитивного решения...
А ведь сработает... и делов-то дописать пять строк.
Спасибо!!!
насчет выставления переменных на передачу данных в конце цикла - истину глаголешь. У меня в проге так сделано. Более того - я параноидально завел две переменные - сurr_value и new_value. В проге все вычисления делаются для new_value, а вот в самом конце сравниваются new_value и curr_value и если они различаются, то
var
DO_1 AT %QX..... : BOOL;
DO_2 AT %QX..... : BOOL;
...
DO_N AT %QX..... : BOOL;
curr_value1 : BOOL := false;
curr_value2 : BOOL := false;
...
curr_valueN : BOOL := false;
end_var
new_value1:=................;
new_value2:=................;
...
new_valueN:=................;
if new_value1 <> curr_value1 then
curr_value1 := new_value1;
DO_1:= curr_value1;
end_if
if new_value2 <> curr_value2 then
curr_value2 := new_value2;
DO_2:= curr_value2;
end_if
...
if new_valueN <> curr_valueN then
curr_valueN := new_valueN;
DO_N:= curr_valueN;
end_if
это уже лишнее, как и if then else. если не равно, то приравниваем, если равно - то нет. какой в этом смысл? приравнивание без условий будет нести абсолютно тот же результат
смысл вот в чем
if new_valueN <> curr_valueN then
curr_valueN := new_valueN;
DO_N:= curr_valueN;
end_if
если не равно - то в сеть посылаем, если равно - то не посылаем.
можете посылать, можете не посылать
результат от действий
do_n := new_val;
и
if new_valueN <> curr_valueN then
curr_valueN := new_valueN;
DO_N:= curr_valueN;
end_if
будет одинаков
Правда чтоль? Серьезно посылаться не будет?
такс, давайте сначала.
у вас есть программа, в которой происходят какие-то действия над переменной new_value. вам надо передать значение этой переменной в модули В/В по rs232/rs485 либо через конфигуратор плк, либо самостоятельно используя библиотеку syslibcom.
если вы в случае использования конфигуратора плк привязываете выходному регистру эту переменную new_value, то получаете это мигание мдвв. причина уже описана.
если же вы заводите пачку "обменных переменных", сажаете их на выходные регистры в конфигураторе и приравниваете этим обменным переменным 1 раз в программе значение своих new_value, то в мдвв будут отсылаться стабильные значения прошлого цикла плк, а не моментально-непредсказуемые текущего.
ну да, и я о том же. Одно НО. Если я хочу минимизировать обмен по сети, то зачем мне записывать новое значение в DO, если это значение не поменялось? Поэтому я и проверяю, поменялось ли значение или нет - еще раз: цель - уменьшить обмен по сети
Поскольку от документации толку ноль, пришлось прочесать сей форум.
Что сделано - для модулей ввода/вывода установлен метод опроса "both" (polling+value change) и время опроса 100 мс. Для модулей вывода установлен метод опроса "by value change" и время опроса 200 мс.
Теперь все работает стабильно
А разве не будут Ваши действия с проверкой избыточны. Если бы Вы самстоятельно реализовывали протокол тогда другое дело, а у Вас:
"both" в любом случае будет обмен через определенный промежуток времени
"by value change" за Вас контроллер проверит изменение переменной
если это значение не поменялось, а в конфигураторе плк у вас настроено "by value change", тут приравнивай, не приравнивай посылка не будет отправлена => не нужны все эти if then else. подойдет простое do := new_value;
p.s. кстати очень интересный параметр "by value change" - отправляет посылку в устройство только по изменению значения. допустим у вас булева переменная отправляется в модуль дискретного вывода, имеет значение true и не меняется аж 30 сек. в модуле сетевой тайм-аут сколько должен быть, чтобы у вас релюшка в нем не выключилась? логично предположить, что больше 30 сек. а если обрыв связи и надо срочно отключить эту релюшку? модуль то переведет ее в безопасное состояние только через 31 сек.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot