Если визирами Вы называете то, что видно в экране отладки - то ничего странно, Sample Trace раб. внутри ПЛК в реальном времени, а среда разработки - не в реальном.
Если визирами Вы называете то, что видно в экране отладки - то ничего странно, Sample Trace раб. внутри ПЛК в реальном времени, а среда разработки - не в реальном.
Я не понимаю.
Протестировал.
Все осталось по прежнему.
Кол-во устройств не имеет значения ошибки идут и с одним.
Если визирам не доверять то тогда я не знаю какая периодичность (посмотрите txt или trc файл).
Подключил еще один блок 7043. У него периодичности никакой нет. Но ошибки сыпяться чаще.
Восстановление нормальной информации (согласно визирам) занимает большой промежуток времени. Если это так то плохо.
Написал свой FB(примитивный через UNM). Опрашиваю ВСЁ - ошибок совсем нет (если не считать одну на каком нибудь устройстве в несколько минут а то реже). При ошибке восстановление происходит при следующем цикле опроса (согласно тем же визирам).
И еще в описании PLC Configuration "Значения выходных переменных (output variables) модуля будут кодироваться в определенный формат и вставляться в передаваемые строки протокола DCON. Данные из строк ответов устройства будут декодироваться и записываться во входные переменные модуля (input variables)", а в примерах наоборот. Может Это как то....
PS [5d] понял исправил. Если можно скиньте Ваш пример с 9 устройствами. Хочу сравнить где не так.
Ошибки могут быть вызваны неск. причинами.
1. Ошибка в формате посылки (практ. нереально)
2. Ошибка в CRC
3. Ошибка четности/к-ва stop битов. - Мастер эту ошибку отслеживает, а при использовании библ. UNM - надо доп. анализировать 2-й байт структуры RBDATA (там флаги). Если Вы этого не делаете то, вероятно, именно в этом дело.
Рекомендации:
1. Дифференцируйте времена опроса параметров, более важные опрашивайте чаще.
2. Выставите параметр "Max response time" как можно меньше (подберите под конкретный прибор, у разн. приборов можно выставить разн. значения), тогда, при ошибке мастер не будет долго ждать ответа. У быстрых приборов может быть 5-10 мс, у медленных доходить до 50-150.
В описании опечатка
В описании опечатка, из входных переменных формируется запрос, в выходные кладется ответ.Сообщение от Сергей71
И еще в описании PLC Configuration "Значения выходных переменных (output variables) модуля будут кодироваться в определенный формат и вставляться в передаваемые строки протокола DCON. Данные из строк ответов устройства будут декодироваться и записываться во входные переменные модуля (input variables)", а в примерах наоборот. Может Это как то....
Пример:
Пример понятен разницы нет за исключением...
Установка maxtimeout больше чем pollingtime не приведет ли к повторному запросу не дождавшись ответа?
И что за ошибка 66(dec). У Вас в описании не полный список ошибок.
Я понял <Выставите параметр "Max response time" как можно меньше> - это "Max response timeout".
Попробовал по разному.
Тест насчет изредка:
Я при ошибке запускаю таймер TON и пока она есть таймер считает мс.
Далее в Trace я смотрю какое время длится ошибка. Т.е наблюдаю некую пилу. И получается что восстановление нормального обмена происходит от 10мс до 600мс с копейками. В принципе 0,5 сек перерыва -куда нешло, но нежелательно. (настройки 50мс опрос, 10мс таймаут, baudrate 38400).
Потом сделал наоборот таймер считает пока нет ошибок. Время получилось 1мин и 3-4 сек - это максимально сколько проработало устройство без ошибок. А так в среднем 20-40 сек и партия ошибок с небольшим интервалом.
Хотел потестить на других скоростях - но нет времени, надо работать.
Если повезет и буду в Москве заеду в гости (сообщите на мыло с кем связаться).
Всем спасибо.
Нет, но это приведет к запаздыванию др. опросов и нарушению периодичности.
Когда она возникла? Эта ошибка не должна возникать.
Именно так.
Весь опрос или опрос отдельного устройства?
Ошибка 66:
команда @04[4h][+]
полож. ответ >[+]
отр. ответ ?
регистр 16input
таймаут 20мс
период опроса 500мс.
<Весь опрос или опрос отдельного устройства?> не понял вопроса.
Поасняю:
У каждого устройства свой таймер.
Происходит так Timer1(IN:= (err>3), PT:= T#10s) и наоборот Timer2(IN:= (err<=3), PT:= T#10m), где err - Status одного устройства. Далее в Trace смотрю оба таймера Timer1.ET и Timer2.ET. Максимально делал с 3-мя устройствами (Все очень быстро движется на экране, а нужно вовремя остановить для просмотра показаний).
Повторил тест с 2.01.8 и таргет 2.0-4. Иногда стал появляться код ошибки 0х02 - модуль послал запрос и ждет ответа, на 2.01.6 ее небыло.
Коды меньше 4 - не ошибки, а лишь отображение происходящих внутри процессов (это может быть необходимо для очень медленных старых DCON-устройств).
про Dcon
Здравствуйте Уважаемые.
Конфигурация:
ПЛК-150УМ, прошивка 2.01.8, Target 2.0-4, 2 модуля М-7055, 1 – МВУ8, 1 пульт ДК-8070.
Протокол DCON и ОВЕН. Кодесис 2.3.8.1.
При обращении к пульту Request format - $$01T[1h][2h][9S][+], фактически же посылает $01T100. Т.е. без строки и контр. Суммы.
На прошивке 1.31.4 и таргет 2.0 работало нормально.
Прошивку обновил потому, что с ПЛК слетела программа,
Что может быть.
И где можно узнать какой таргет в данный момент установлен?.
А standart configuration Вы делали
Какой таргет сейчас стоит можно узнать из
C:\CoDeSys\Targets\НАЗВАНИЕ ВАШЕГО ПЛК\IOModules\hardware.cfg
Ваши права
