Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
Вид для печати
Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
Проект, версии ПО, Это М02 или в девичестве М01, Какое оборудование подключаете? Если закрыть-открыть порт библиотекой связь восстанавливается?Цитата:
Сообщение от lazy
ПЛК110-220.30.K-M;
ID 54224160432047779;
CoDeSys 2.3.9.38 (Build Jan 17 2013);
Target PLC110.30_m_v2 1.1.0.0 с диска;
Подключаю сенсорную панель "Kinco" MT4424TE.
По поводу ПО. В части общения с панелями код не меняется из проекта в проект и их уже работает куча, никогда проблем не возникало. Вчера вечером залил один и тот же проект на старый 110+Kinco и на новый 110+Kinco часа четыре отпахали без сбоев - оставил на ночь. Утром - старый пашет, новый озяб. )
С утра хватило на полтора часа. Если порт закрыть/открыть связь восстанавливается.
Вы ошибаетесь коллега, это прекрасный ПЛК, в нем не может быть такого)))))).Цитата:
Сообщение от lazy
Всё ещё не понятно, Сообщите версию ПО ПЛК и проект(в личку).Цитата:
Сообщение от lazy
P.S.А в проекте Вы не контролируете статус связи и при длительном (10-20 посылок) отсутствии не производите переинициализацию(не важно,сокет,порт или что ещё)?
P.P.S. Я планирую поставить ПЛК на длительный тест по 232 портам в понедельник, но Ваш проект всё ещё актуален,т.к.могут быть нюансы
В понедельник рано утром уезжаю в командировку буду на работе скорее уже на следующей неделе.Цитата:
Сообщение от Филоненко Владислав
Переинициализация происходит конечно, но она на кнопке "сброс ошибок" которая на сенсорной панели :D
Да и проблем ни с портами ни с сокетами никогда не возникало.
Мы поставили ПЛК на суточное тестирование - 232 не упал. Нужен проект для воспроизведения ошибки
Отправил проект в личку. Точнее, попытался )
Теперь и я в отпуске. Попробую договорится о тестировании с коллегами.
Вот, что случайно удалось обнаружить. В том проекте который я отправил, удалив бОльшую его часть, запросы по RS232 отправлялись максимально часто. То есть, 1-й цикл - отправляем запрос на чтение/запись, какое то количество циклов ждем ответ (на старом 110м один - три цикла, на новом так как производительность больше, проходит и больше циклов ожидания, на вскидку раз в пять) получили ответ - в следующем цикле снова шлем запрос. Опять же из за производительности эта задержка между приемом старого запроса и посылкой нового на старом 110м получается длиннее раз в пять сама собой из-за более длительного времени цикла. Старые 110е разъехались клиентам и я тренируюсь на новом. Сейчас есть проект в котором критична скорость обмена по RS485 и выполнение бОльшей части кода в ПЛК происходит в моменты ожидания ответов по RS485му. То есть, в том числе и запросы по RS232 отсылаются реже, получил ответ по 485му - отправил запрос по 485му и 232му и смотреть ответ по 232му я буду только когда получу ответ по 485му и соответственно, отсылать по 232му новый запрос буду только когда получу следующий ответ по 485му. Получилось, что задержки между запросами по 232му увеличились как раз в те самые пять раз (ну так... приблизительно) ...и 232й перестал отваливацо, по крайней мере так отпахал уже сутки без сбоев. По 485му шлю новый запрос в том же цикле в котором получаю ответ и все ОК. Путано, конечно, но может чем-то поможет. )
это как такое возможно, это два не зависимых порта и в проекте можно ожидать ответа от каждого из них не зависимо от другогоЦитата:
Сообщение от lazy
Вы помоему перепутали применение такой конструкции при опросе нескольких модулей по одному интерфейсу
Ну почему же, ответ получен, он лежит в буфере и ничего с ним не произойдет. Когда этот буфер читать (в каком цикле) какая разница? Просто, на все уходит время и читать буфер 232го, а так же делать прочие полезные вещи, я хочу пока ходят запросы/ответы по 485му.
начять нужно с того, что за прием данных из порта отвечает отдельная микросхема, её глубоко безразлично, что происходит в самом плк, она среагировала на мусор в сети и переписала буффер, ей чуждо гарантировать хранение информации в прошлом, если даже оно измеряется в миллисекундахЦитата:
Сообщение от lazy
какое время? Выполнение функции занимает микросекунды, на сам цикл плк это не оказывает ни какого влияния, по большому счету это время равно или даже меньше, чем тот комплекс мероприятий, чтоб выполнять эту же самую функцию по какому то специфичному законуЦитата:
Сообщение от lazy
С тем что данные в буфере портятся пока не сталкивался, пусть даже и так, при чтении ошибка обнаружится. Для меня не критичны в данном случае единичные ошибки на 232м (тем более, что их нет). А вот на 485м новые данные появляются через каждые 20ms и если запрос/ответ 20-22ms - это одно, а когда 18-20ms - это совсем другое.
ну и в чем проблема, обеспечение регулярности запросов обычно делают через таймер, он не смотрит какой сейчас по счету цикл, он сравнивает время и отправляет начальный пакет, хоть один цикл пройдет, хоть пять, главное чтоб период подошел для отправки. И какая тут связи между разными портами?Цитата:
Сообщение от lazy
Проблема в том, что если время между ответом и новым запросом 5мс - 232й не падает, а если 1мс - падает (со временем и время от времени). Время условно и приблизительно. Один и тот же код на одном ПЛК работает, а на другом нет - меня это напрягает, вас, может быть нет )
перечитайте спецификацию модбасРТУ, какова должна быть пауза между пакетами, для того чтоб протокол работалЦитата:
Сообщение от lazy
это не проблема портов и не проблема плк
Я время точно не меряю, это так... приблизительно. Время цикла на новом ПЛК 1мс на старом 5мс, плюс минус. 485й же не отваливается даже если новый запрос слать в том же цикле в каком ответ получен. Может быть это и "Кинко" отваливается (если вы о 1.75мс). Щя проверю, сброшу питание на панели как только порт озябнет и отпишусь )
По стандарту RTU пауза должна быть не менее 3.5 символов, но на больших скоростях допускается и 1 мс и более.
А если подключить не к 232 а к DBGU?
Нет, панель не причем. )Цитата:
Сообщение от lazy
Мой косяк. Вопрос снят )
А расшифровать в заглавном посте что было не как для потомков?
Да нашел один указатель не инициализированный. Хотя... Одно время и с ним работало несколько дней без сбоев. И как нашел-исправил тоже отваливалось несколько раз уже. Проект еще пишется и косяки в нем есть канеш. Но и в ПЛК чую чота сидит. на старом то пахало и пашет )Цитата:
Сообщение от Филоненко Владислав
Если соберетесь на проекте моем погонять там нужно в действии Initialize, блоку fbRegs, переменной i_pFR присвоить адрес m_FR по аналогии )