Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
ПЛК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; 10.11.2016 в 10:42.
Всё ещё не понятно, Сообщите версию ПО ПЛК и проект(в личку).
P.S.А в проекте Вы не контролируете статус связи и при длительном (10-20 посылок) отсутствии не производите переинициализацию(не важно,сокет,порт или что ещё)?
P.P.S. Я планирую поставить ПЛК на длительный тест по 232 портам в понедельник, но Ваш проект всё ещё актуален,т.к.могут быть нюансы
Тролль-наседка, добрый, нежный и ласковый
Мы поставили ПЛК на суточное тестирование - 232 не упал. Нужен проект для воспроизведения ошибки
Тролль-наседка, добрый, нежный и ласковый
Отправил проект в личку. Точнее, попытался )
Теперь и я в отпуске. Попробую договорится о тестировании с коллегами.
Тролль-наседка, добрый, нежный и ласковый
Вот, что случайно удалось обнаружить. В том проекте который я отправил, удалив бОльшую его часть, запросы по RS232 отправлялись максимально часто. То есть, 1-й цикл - отправляем запрос на чтение/запись, какое то количество циклов ждем ответ (на старом 110м один - три цикла, на новом так как производительность больше, проходит и больше циклов ожидания, на вскидку раз в пять) получили ответ - в следующем цикле снова шлем запрос. Опять же из за производительности эта задержка между приемом старого запроса и посылкой нового на старом 110м получается длиннее раз в пять сама собой из-за более длительного времени цикла. Старые 110е разъехались клиентам и я тренируюсь на новом. Сейчас есть проект в котором критична скорость обмена по RS485 и выполнение бОльшей части кода в ПЛК происходит в моменты ожидания ответов по RS485му. То есть, в том числе и запросы по RS232 отсылаются реже, получил ответ по 485му - отправил запрос по 485му и 232му и смотреть ответ по 232му я буду только когда получу ответ по 485му и соответственно, отсылать по 232му новый запрос буду только когда получу следующий ответ по 485му. Получилось, что задержки между запросами по 232му увеличились как раз в те самые пять раз (ну так... приблизительно) ...и 232й перестал отваливацо, по крайней мере так отпахал уже сутки без сбоев. По 485му шлю новый запрос в том же цикле в котором получаю ответ и все ОК. Путано, конечно, но может чем-то поможет. )