как сразу "подвешать" всё оборудование на плк100 , 150

сегодня внезапно встало всё оборудование , базирующееся на контроллерах плк 100,150 в разгар рабочего дня . причина находилась на расстоянии в километры от места расположения плк.дело в том , что
они все находятся в одной подсети Tcp , подключены каждый к своему Pc и некоторые обмениваются сетевыми переменными (таргеты 2.10.4, прошивки 2.10).на отдельной ветке Tcp (в тойже подсети), по ошибке , неправильно соединили между собой свитчи (пустили параллельно второй кабель).в сетке видимо пошли коллизии. и все контроллеры сбросились , на них светился только светодиод "питание",перестали пинговаться (даже после восстановления исправности сети). восстановить работу получилось только после сброса кнопкой каждого прибора в отдельности.
такая ситуация немного "напрягла" , т.к. неизвестно в какой момент во время техпроцесса может случиться подобная ситуация , и к каким последствиям это приведёт в плане сохранности оборудования ,безопасности труда и элементарного простоя. было бы хорошо , если вне зависимости от исправности сети Tcp,
контроллеры сохраняли устойчивость и продолжали работать по заложенной программе. пусть даже пропадёт связь плк с Pc и обмен сетевыми переменными , это не страшно.

прошу извинить за хаос с заглавными буквами , но вылавливать логику их поведения лучше специалистам ...

не далее как на прошлой неделе на аналоговый вход прибора подали 380 вольт.... сгорели микросхемы, перестал работать. пришлось отдать в ремонт.
к сожалению нет в жизни совершенства...

думаю ,что в сложных системах должна быть защита от "дурака".ведь число Ip-ов в сети может достигать десятков и сотен, и это не означает , что при обрыве или замыкании кабеля Tcp в какой-то из веток все компьютеры и специальные устройства должны виснуть и сбрасываться вместе с запущенными на них программами и потерей промежуточных результатов работы . ведь висанули только плк100,150 (5штук) ; все остальные компы и контроллеры пережили это
безболезненно. подобные проблемы(перезагрузки плк) наблюдались и при использовании Modbus Tcp (как Master , так и Slave). попробуйте посчитать сколько суммарно сотен метров ,а то и километров Tcp кабелей и хабов в среднем на предприятиях , и станет понятна степень уязвимости . думаю проблема в малой программной защищённости Tcp порта контроллера плк . с надеждой будем ждать новых версий прошивок с решённой проблемой или др.предложений . думаю эта проблема (сброс контроллера при неисправности сетки) может коснуться каждого пользователя , пропорционально колличеству плк в сети.

это проблема правильного написания отказоустойчивой программы - нет связи - работаем по другой ветке.
коллизий при коммутаторе не бывает в принципе.
поэтому расскажите здесь, чтоже всетаки произошло в вашей сети?

Цитата:

---

Сообщение от ASo

коллизий при коммутаторе не бывает в принципе.

---

broadcast storm...
за DDOSили...

нормальные условия : для объединения абонентов сети коммутатор Compex Ps-2216 подключен к другому (в качестве него Asus 500g ) одним кабелем.
по случайности их же соединили между собой ещё и вторым кабелем , после этого возникли описанные выше проблемы.

ну я и говорю - бродкаст....

согласен. давайте только называть вещи своими именами (с)

К сожалению, UDP используется для сетевых переменных и если в сети есть большое количество бродкаст UDP - ПЛК будет жутко тормозить, пытаясь их обработать.
Отключить это нельзя, т.к. тогда не будет работать сетевые переменные.
Не могли бы Вы прислать логи с контроллеров (dubug.txt. log.txt) и указать время, когда был сбой.

Ок. Подвисание произошло 10_06_2009г в районе 14 часов дня , судя по файлу в 14.20 . Файлы взяли с 2-х контроллеров , в других видимо будут подобные.
ПЛК 100 и 150 с прошивкой 2.10.4 Target 2.10 .

Кстати , один контроллер из всех не потребовал нажатия на нём кнопки RESET. К нему просто перконектились CoDeSys-ом .Файлы ПЛК11 приложены (время на нём со сдвигом минус 1 час). Видимо он всё-таки перегружался , но окончательно не завис. На нём единственном стоит прошивка 2.02.8, на других 2.10.4.

Ситуация с подвисанием контроллеров повторилась при других условиях .

При использовании программы "Advanced IP Scaner v1.5" ( http://www.radmin.ru/ ),после выбора рабочего диапазона для сканирования 131.132.133.1 - 131.132.133.255 ( здесь же находятся и ПЛК ) и запуска
( SCAN ) произошло подвисание 3-х из 5-ти контроллеров . Также они после этого перестали пинговаться и помог только аппаратный сброс.
Совпадение или нет , но на одном время стало нулевым, не тикает и невозможно его изменить , перестал пикать зуммер при нажатии сброса, загораются не все светодиоды при сбросе ,перепрошивка не помогает .PLC INFO показывает версию верхней платы 00. Видимо с ней какие-то проблемы ? Пока время для него берём с другого контроллера через сетевые переменные ,это спасает,т.е. позволяет продолжить работу, но из индикаторов светится только"питание" .(Прошивка 2.10.4 ,Target 2.10,IP 131.132.133.10, 131.132.133.11 ,131.132.133.15, GATEWAY для всех: адрес одного компа 131.132.133.27,первые 4-е цифры в MAC адресах поменяны на 00-80 на всех ПЛК , с родными не через все коммутаторы идёт связь) .Что можно предпринять ?

Цитата:

---

совпадение или нет , но на одном время стало нулевым, не тикает и невозможно его изменить , перестал пикать зуммер при нажатии сброса, загораются не все светодиоды при сбросе ,перепрошивка не помогает .plc Info показывает версию верхней платы 00

---

были подобные симптомы при объединении нескольких контроллеров (5 штук) в сеть и попытке завязать их через сетевые переменные. контроллеры для этого перепрошивали на более свежие прошивки. сначала вылетел один, через неделю другой. тех. поддержка утверждала, что платки верхние отваливаются, перепаяли всё не один раз. но более нескольких дней контроллеры на объекте не работали. поставили новые 2008 года с теми же свежими прошивками. работают 4 месяца без вопросов.

даа...не прикольно. контроллеры у нас 2007...2008года,хочется надеяться что не все платки поотключаются. что делать ?! как лечить ? отсоединять
все провода от плк, вскрывать ,тыркать платку ,надеяться на удачу , тратить 1-2 рабочих дня на эксперименты (в т.ч. тысячи рублей рабочего времени
специалистов), потом при неуспешности излечения заказывать подобный ,а в это время ,чтобы не простаивало оборудование, спешно , в рабочее и вне
рабочее время перекидывать проект под другой контроллер .
хотелось бы оперативно получать рекомендации от техподдержки ! а усилия тратить на создание новых интересных проектов и оборудования и , меньше, на тестирование.
думается что удобство замены неисправных плк хорошо
реализовано на плк110 с быстросъёмными колодками, а то в плк100 переподключение всех проводов довольно муторное занятие ,требующее подписывания всех проводков.

По логу происходит перезагрузка по питанию. Не могли бы Вы прислать настройки программы RAdmin и маки/IP подвисших и не подвисших ПЛК. Попробуем воспроизвести ситуацию.

Ip адреса подвисших контроллеров : 131.132.133.10 , 131.132.133.11, 131.132.133.12, 131.132.133.15, 131.132.133.16. эксперимент с Ip Scanerom повторили,
нажав кнопку Scan и через секунду стоп , этого уже хватило ,чтобы все контроллеры отбились от своих компов . (программа Radmin Viewer и Remoute Administrator Server в сети работают нормально , сбои наблюдаются только при использовании программы Remote Ip Scaner в режиме запущенного сканирования активных Ip-ов в сети) . по поводу неисправности верхней платы ; есть предположение , что активная работа с сетевыми переменными вызывает дополнительный нагрев элементов. т.к. в контроллере с неработающей верхней платой наблюдается температура 50 гр , в то же время в других : 31 , 43 гр...

Работать с контроллером без световой индикации , молчаливым и не наблюдающим часов конечно как бы можно, но минусов много ... Ооочень хочется увидеть контроллер вновь полноценным. Предпринятые меры для восстановления верхней платы :
1.Разборка корпуса ,визуальный осмотр плат и разъёмов.
2.Пропайка разъёма.
3.Проверка аккумулятора.
Не помоглооооо...

Понимаю так , средняя плата убивает (программно)верхнюю.

Сняли гипертерминалом загрузочный отчёт по сбросу.
Прилагаем в прицепе. Просим проанализировать ...

1.Может ли средняя плата, используя программные спецсредства восстановить прошивку верхней платы взад?
2.Можно ли заказать верхних плат,чтобы не оставлять
оборудование без головы на время ремонта ПЛК?

[QUOTE

Понимаю так , средняя плата убивает (программно)верхнюю.

Сняли гипертерминалом загрузочный отчёт по сбросу.
Прилагаем в прицепе. Просим проанализировать ...
[/QUOTE]

А как можно убить программно то в чем программного практически нету.
Овенцы утверждають , что они аппаратно ничего не меняють , меняются только прошивки.
Сами подумайте контроллер выпущен в конце 2007г , за это время вышло аж 3 прошивки!?!
Попробуйте просто купить новые контроллеры , а старые как - нибудь убейте и сдайте в ремонт.
Самое лучшее что есть в контроллерах Овен- это CoDeSys и цена,без этого-это просто хлам.
P.S UDP обмен по моему мнению - средство для локального обмена между контроллерами в одной маленькой сетке, я реализовал UDP обмен на одном проекте когда у меня не пощел TCP-modbus,потом я нашел в чем собака порылась но UDP оставил,так как ресурсов не требует.
Поэтому НЕ ЗАПУСКАЙТЕ свое вредоносное ПО,а если хотите вольно работать по TCP - есть TCP Modbus и его описание пишите и работайте.

даже и не знаю что сказать на этот эмоциональный пост. Все .... один я в белом на коне и с шашкой. Все вперед в светлое будущее...

Цитата:

---

Сообщение от Филоненко Владислав

даже и не знаю что сказать на этот эмоциональный пост. Все .... один я в белом на коне и с шашкой. Все вперед в светлое будущее...

---

За эмоциональность ,конечно,извиняюсь просто приехал с объекта очень поздно,усталый и злой.
Ситуация такая с UDP обменом работают 2 плк100 и 1плк150 , и после недавней грозы в работе системы начались сбои.Т.е с неработающей ,а может быть частично неработающей, верхней платой контроллеры работают,но синхронизации нет и программа ,фиксируя нарушение обмена останавливает работу,потом (ч-з 2-3 сек ) обмен восстанавливается , работа возобнавляется.
Причем подключится к контроллерам получилось , как по DEBUG , так и по TCP .
ПЛК150 вылечила перепрошивка стояла 2.05 поставил 2.06 , а ПЛК 100 ,получив файл PLK100.BIN и команду UpdateCore , издох.
Пришлось потратить много времени на то ,чтобы вместо плк100 установить плк150(он был в наличии на тот момент),так как утром система ДОЛЖНА работать.
Да , кстати,а что с технической документацией и с примерами программ,я имею в ввиду на диске ,который идет с ПЛК.
Ничего нету!
Ни одного примера с данного форума!Особенно примеры И развернутые описания системных библиотек.
Пользователь , который только начинает работу с ПЛК , понятия не имеет о данном форуме.Или это такой метод воспитания , типа только пройдя огонь и воду можно стать самураем ,хватать шашку и залезать на коня.

Абсолютно согласен. Бывают моменты , когда время летит стремительно и для решения срочной задачи не хватает уже и вечера , и ночи . Здесь как раз кстати , бывают своевременные советы опытных пользователей (энтузиастов своего дела). Особенно нервирует , когда скрытые глюки аппаратуры неумышленно заложены изготовителем и специальные оговорки об этом в паспорте отсутствуют.
Уже позже , при написании и отладке проекта, приходится о них спотыкаться.
В плане оперативности техподдержки , понравился Schneider , где в ответ на E-Mail вопрос , практически сразу приходит сообщение ,что Ваше письмо зарегистрировано под таким-то номером и ответ Вы получите в течении 1(2)дней.И что интересно исчерпывающий ответ своевременно приходит. Может какие-то моменты позаимствовать !?
Хотя глюков похоже хватает и у них. Одним из последних было отставание встроенных часов на 10...15 мин в сутки у контроллера с CoDeSys (с небольшой стоимостью 7...9тыс.руб), встраиваемого в частотник ATV71 .
Исправить который оказывается можно только заменой (видать недотестили). В связи с этим радует , что многие вопросы с ПЛК100,150 решаются путём перепрошивки, без отправки контроллера изготовителю. Предлагаем небольшую доработку корпуса ПЛК , позволяющую меньше крутить винтов при необходимости съёма корпуса (избежать ошибок,сберечь контакты).Фото в приложении.

Ситуация ,описанная SergeyNG , повторилась и в нашем случае. Спустя 1...2 месяца после установки прошивки 2.10.5 перестало идти время на ПЛК150УМ (второй из пяти ПЛК ,с прошивками 2.10.5,обмен сетевыми переменными),также ,как и в первом случае в PLCInfo показывает: Pic upper Version is 00,светодиоды не работают,кроме индикатора "Питание" (первым был ПЛК100РЛ).Можно было бы этим пренебречь , но время используется для отчётов и др.,т.е. оно нужно.Итого, на разном оборудовании уже два контроллера с неработающими верхними платами, которые мы не можем снять на несколько недель для отправки в ремонт,т.к. остановятся станки. Может попытаться найти найти решение с программным восстановлением прошивки верхней платы через модернизированный файл Update Core ?
Возможен ли вариант , в целях поддержки клиентов, производить замену контроллеров у диллеров по принципу : сдал неисправный и сразу забрал новый такого же типа . Это сразу сняло бы много вопросов со стороны потребителей , т.к. поломки происходят не по их вине. Думаю введение такого режима обмена было бы не очень накладно для Вашей организации , но было бы очень удобно, ведь даже при сдаче в ремонт простого телефона, фирмы на время ремонта выдают другой для использования.

Прошивку 2.10.7 опробуем в ближайшее время.

прошу прощения, что влез, может быть кто нибудь кинет сюда код с помощью которого мы присваиваем переменной значение даты/времени в плк?

в примерах программ и полезностях есть работа со временем.