Вот теперь, с прошивкой v2.00.2, все измеряется точно.
Спасибо.
Вид для печати
Вот теперь, с прошивкой v2.00.2, все измеряется точно.
Спасибо.
проверте, нет ли ошибки в таргет файле для контроллера 100 Rl. у меня при создании нового проекта при выборе котроллера 100 Rl в конфигурации появляется 100.к. соответственно есть возможность не только "сработать" реле но и зажечь светодиодик рядом. это удобно, но нет ли тут подводных камней...
в таргете ошибки нет. повидимому у вас неправильно установился таргет
P.s. такое использование не опасно.
Контроллер иногда самостоятельно перезагружается, иногда входит в "стоп" оставлял работать на ночь два раза и вот такой результат. Периодически проходит сбой адресации модбас мастер, в результате получает неверные переменные. Причем лечится это только restart original и затем запись той же самой программы. Кстати, довольно странно то, что модбас адрес в icp 8000 на единицу больше адреса в ПЛК Овен. Откуда это пошло?
Прошивка последняя, таргет последний. Могу выслать проект, но система работает в связке icp (модель) - RS485 - ПЛК (регуляторы) -Ethernet - OPC - SCADA. Так что не знаю, как поточнее передать суть проблемы.
Добрый день!
1. Что такое сбой адресации?
По поводу различия адресов регистров - сущ. 2 стандарта, 1-й начинает отсчет регистров с 0, а во втором с 1. Всё на совести производителей.
2. Для анализа, почему происходят сбои рекомендую следующее:
Подкл. отладочный кабель без перемычки. Настроить гипертерминал на запись лога с ПЛК. Запустить ПЛК, загрузить программу через Ethernet, поставить на прогон. Если сбои случаться, прислать записанный лог нам.
P.S. Ещё раз напоминаю, что мы не рекомендуем эксплуатировать ПЛК в общем сегменте сети Ethernet. Особенно следует обратить внимание на блокировку широковещетельных UDP пакетов из общей сети.
Владислав, здравствуйте.
Я не понятно выразился "сбой адресации", попытаюсь пояснить. В определенный момент, я заметил при перепрошивке и перезапуске второго (icp) контроллера, ПЛК 100 начинает принимать значения как бы со сдвигом. То есть читает с адреса 16#3 то, что на самом деле расположено в другом контроллере по адресу 16#7, с адреса 16#7 - то что 16#b и т.д. по всем переменным.
Воскресение проработал без сбоев. Для связи с ПЛК установлена отдельная сетевая карта, маршрутизатор не запущен.
Что можно предположить:
Если все чтения однотипны (например регистров), и опрашиваемый прибор имеет слишком большое время формирования ответа (>MaxResponseDelay),
то при циклическом опросе переменных ПЛК не дождется ответа на запрос к адресу 0х03, пошлет запрос к адресу 0х07, и тут приходит запоздавший ответ на запрос по адресу 0х03. Протокол ModBus не позволяет прибору различить эти 2 ответа. (сам наблюдал такую странную картину, искал ошибку:mad: , пока не дошло, в чём дело:) )
Лечение:
2 пути:
1. Если прибор просто тупой и медленный - увеличиваем MaxResponseDelay
2. Если задержки бывают изредка, то можно попробовать в опрашиваемых переменных чередовать команды, т.е. 1-я читает командой 0х03, вторая 0х04, третья 0х03 и т.д. В этом случае ПЛК отсечёт запоздавший пакет по номеру команды.
Спасибо, учту.
Добавлю еще что переменные передаются следующим образом вначале 0х06 на адрес 16#20, затем четыре 0х03 с адресов 16#3, 16#7, 16#b и 16#f. Может это как-то поможет в решении.
На самом деле контроллер в режиме по таймеру начинает опрашивать переменные с конца, т.е. сначала 16#f, затем 16#b и т.д.таким образом, описанный мною вариант с запаздыванием ответа вполне возможен.