Просмотр полной версии : ПЛК 110.30-M v2 & RS-232
Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
Филоненко Владислав
09.11.2016, 21:05
Добрый день!
Через час-два работы ПЛК 110.30-M v2 отваливается RS-232. Скорость 115200. Modbus.lib. После выключения или сброса ПЛК - связь восстанавливается. На старом железе (прошлой версии 110го) код работает без сбоев.
Проект, версии ПО, Это М02 или в девичестве М01, Какое оборудование подключаете? Если закрыть-открыть порт библиотекой связь восстанавливается?
ПЛК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 часа четыре отпахали без сбоев - оставил на ночь. Утром - старый пашет, новый озяб. )
С утра хватило на полтора часа. Если порт закрыть/открыть связь восстанавливается.
Николай Федоров
11.11.2016, 22:55
ПЛК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 часа четыре отпахали без сбоев - оставил на ночь. Утром - старый пашет, новый озяб. )
С утра хватило на полтора часа. Если порт закрыть/открыть связь восстанавливается.
Вы ошибаетесь коллега, это прекрасный ПЛК, в нем не может быть такого)))))).
Филоненко Владислав
12.11.2016, 07:08
ПЛК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 часа четыре отпахали без сбоев - оставил на ночь. Утром - старый пашет, новый озяб. )
С утра хватило на полтора часа. Если порт закрыть/открыть связь восстанавливается.
Всё ещё не понятно, Сообщите версию ПО ПЛК и проект(в личку).
P.S.А в проекте Вы не контролируете статус связи и при длительном (10-20 посылок) отсутствии не производите переинициализацию(не важно,сокет,порт или что ещё)?
P.P.S. Я планирую поставить ПЛК на длительный тест по 232 портам в понедельник, но Ваш проект всё ещё актуален,т.к.могут быть нюансы
Всё ещё не понятно, Сообщите версию ПО ПЛК и проект(в личку).
В понедельник рано утром уезжаю в командировку буду на работе скорее уже на следующей неделе.
Переинициализация происходит конечно, но она на кнопке "сброс ошибок" которая на сенсорной панели :D
Да и проблем ни с портами ни с сокетами никогда не возникало.
Филоненко Владислав
17.11.2016, 11:20
Мы поставили ПЛК на суточное тестирование - 232 не упал. Нужен проект для воспроизведения ошибки
Отправил проект в личку. Точнее, попытался )
Филоненко Владислав
22.11.2016, 19:35
Теперь и я в отпуске. Попробую договорится о тестировании с коллегами.
Вот, что случайно удалось обнаружить. В том проекте который я отправил, удалив бОльшую его часть, запросы по RS232 отправлялись максимально часто. То есть, 1-й цикл - отправляем запрос на чтение/запись, какое то количество циклов ждем ответ (на старом 110м один - три цикла, на новом так как производительность больше, проходит и больше циклов ожидания, на вскидку раз в пять) получили ответ - в следующем цикле снова шлем запрос. Опять же из за производительности эта задержка между приемом старого запроса и посылкой нового на старом 110м получается длиннее раз в пять сама собой из-за более длительного времени цикла. Старые 110е разъехались клиентам и я тренируюсь на новом. Сейчас есть проект в котором критична скорость обмена по RS485 и выполнение бОльшей части кода в ПЛК происходит в моменты ожидания ответов по RS485му. То есть, в том числе и запросы по RS232 отсылаются реже, получил ответ по 485му - отправил запрос по 485му и 232му и смотреть ответ по 232му я буду только когда получу ответ по 485му и соответственно, отсылать по 232му новый запрос буду только когда получу следующий ответ по 485му. Получилось, что задержки между запросами по 232му увеличились как раз в те самые пять раз (ну так... приблизительно) ...и 232й перестал отваливацо, по крайней мере так отпахал уже сутки без сбоев. По 485му шлю новый запрос в том же цикле в котором получаю ответ и все ОК. Путано, конечно, но может чем-то поможет. )
смотреть ответ по 232му я буду только когда получу ответ по 485му
это как такое возможно, это два не зависимых порта и в проекте можно ожидать ответа от каждого из них не зависимо от другого
Вы помоему перепутали применение такой конструкции при опросе нескольких модулей по одному интерфейсу
Ну почему же, ответ получен, он лежит в буфере и ничего с ним не произойдет. Когда этот буфер читать (в каком цикле) какая разница? Просто, на все уходит время и читать буфер 232го, а так же делать прочие полезные вещи, я хочу пока ходят запросы/ответы по 485му.
Когда этот буфер читать (в каком цикле) какая разница?
начять нужно с того, что за прием данных из порта отвечает отдельная микросхема, её глубоко безразлично, что происходит в самом плк, она среагировала на мусор в сети и переписала буффер, ей чуждо гарантировать хранение информации в прошлом, если даже оно измеряется в миллисекундах
Просто, на все уходит время
какое время? Выполнение функции занимает микросекунды, на сам цикл плк это не оказывает ни какого влияния, по большому счету это время равно или даже меньше, чем тот комплекс мероприятий, чтоб выполнять эту же самую функцию по какому то специфичному закону
С тем что данные в буфере портятся пока не сталкивался, пусть даже и так, при чтении ошибка обнаружится. Для меня не критичны в данном случае единичные ошибки на 232м (тем более, что их нет). А вот на 485м новые данные появляются через каждые 20ms и если запрос/ответ 20-22ms - это одно, а когда 18-20ms - это совсем другое.
С тем что данные в буфере портятся пока не сталкивался, пусть даже и так, при чтении ошибка обнаружится. Для меня не критичны в данном случае единичные ошибки на 232м (тем более, что их нет). А вот на 485м новые данные появляются через каждые 20ms и если запрос/ответ 20-22ms - это одно, а когда 18-20ms - это совсем другое.
ну и в чем проблема, обеспечение регулярности запросов обычно делают через таймер, он не смотрит какой сейчас по счету цикл, он сравнивает время и отправляет начальный пакет, хоть один цикл пройдет, хоть пять, главное чтоб период подошел для отправки. И какая тут связи между разными портами?
Проблема в том, что если время между ответом и новым запросом 5мс - 232й не падает, а если 1мс - падает (со временем и время от времени). Время условно и приблизительно. Один и тот же код на одном ПЛК работает, а на другом нет - меня это напрягает, вас, может быть нет )
Проблема в том, что если время между ответом и новым запросом 5мс - 232й не падает, а если 1мс - падает (со временем и время от времени). Время условно и приблизительно. Один и тот же код на одном ПЛК работает, а на другом нет - меня это напрягает, вас, может быть нет )
перечитайте спецификацию модбасРТУ, какова должна быть пауза между пакетами, для того чтоб протокол работал
это не проблема портов и не проблема плк
Я время точно не меряю, это так... приблизительно. Время цикла на новом ПЛК 1мс на старом 5мс, плюс минус. 485й же не отваливается даже если новый запрос слать в том же цикле в каком ответ получен. Может быть это и "Кинко" отваливается (если вы о 1.75мс). Щя проверю, сброшу питание на панели как только порт озябнет и отпишусь )
Филоненко Владислав
24.11.2016, 18:25
По стандарту RTU пауза должна быть не менее 3.5 символов, но на больших скоростях допускается и 1 мс и более.
А если подключить не к 232 а к DBGU?
Может быть это и "Кинко" отваливается
Нет, панель не причем. )
Филоненко Владислав
09.12.2016, 13:40
А расшифровать в заглавном посте что было не как для потомков?
А расшифровать в заглавном посте что было не как для потомков?
Да нашел один указатель не инициализированный. Хотя... Одно время и с ним работало несколько дней без сбоев. И как нашел-исправил тоже отваливалось несколько раз уже. Проект еще пишется и косяки в нем есть канеш. Но и в ПЛК чую чота сидит. на старом то пахало и пашет )
Если соберетесь на проекте моем погонять там нужно в действии Initialize, блоку fbRegs, переменной i_pFR присвоить адрес m_FR по аналогии )
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot