Просмотреть полную версию : Рвутся связи между контроллерами
У нас на объекте после пропадания питания пропала связь между контроллерами (переменные с одного не поступают на другой).
В сети Modbas: 2Gi (Slave-RS485) - C2010-1212-01-0 - C2010-1312-01-0 - 2G (Master-RS485) - C2010-1312-01-0
К 2G по RS232 (Slave) подключен еще самописец (Master)
На данный момент связь восстанавливается перепрошивкой контроллеров.
PS Такие обрывы связи происходят достаточно регулярно. Как с этим бороться?
У нас на объекте после пропадания питания пропала связь между контроллерами (переменные с одного не поступают на другой).
В сети Modbas: 2Gi (Slave-RS485) - C2010-1212-01-0 - C2010-1312-01-0 - 2G (Master-RS485) - C2010-1312-01-0
К 2G по RS232 (Slave) подключен еще самописец (Master)
На данный момент связь восстанавливается перепрошивкой контроллеров.
PS Такие обрывы связи происходят достаточно регулярно. Как с этим бороться?
Обновите прошивки в контроллерах 2Gi и 2G до последних версий.
И попробуйте пустить в работу весь комплект без самописца. Т.к. если самописец производит запись в недопустимые области памяти, то в 2G вполне может повредиться программа и он вполне может завесить сеть. Это как раз перепрошивкой возможно вы и лечите.
Обновите прошивки в контроллерах 2Gi и 2G до последних версий.
И попробуйте пустить в работу весь комплект без самописца. Т.к. если самописец производит запись в недопустимые области памяти, то в 2G вполне может повредиться программа и он вполне может завесить сеть. Это как раз перепрошивкой возможно вы и лечите.
Во всех контроллерах самые последние версии ядер.
Самописец подключен по схеме: 2G-RS232 - преобразователь RS485/RS232 - самописец-RS485
Я конечно непонимаю принцип работы передачи данных по ModBas, но 2G только отправляет данные на самописец и ничего от него неполучает. Как самописец может че-нить не туда записать?
Сегодня произошол обрыв связи с одним из С2010 (с остальными контроллерами связь была). Перепрошивка 2G и 2Gi не дала результатов. Удалось восстановить связь только перепрошивкой именно этого контроллера.
Во всех контроллерах самые последние версии ядер.
Самописец подключен по схеме: 2G-RS232 - преобразователь RS485/RS232 - самописец-RS485
Я конечно непонимаю принцип работы передачи данных по ModBas, но 2G только отправляет данные на самописец и ничего от него неполучает. Как самописец может че-нить не туда записать?
Из вашего описания я понял, что мастером является самописец.
Сегодня произошол обрыв связи с одним из С2010 (с остальными контроллерами связь была). Перепрошивка 2G и 2Gi не дала результатов. Удалось восстановить связь только перепрошивкой именно этого контроллера.
Т.е не помогает ни выключение питания, ни вынимание и засовывание провода связи?
PS. Последние версии - это какие? Озвучьте пожалуйста.
Из вашего описания я понял, что мастером является самописец.
Самописец является мастером в сети RS232, а по сети RS485 мастером является 2G.
Т.е не помогает ни выключение питания, ни вынимание и засовывание провода связи?
Именно. Перепробовали все: и :ico-shama и :godd: и:book: ничего не помагало.
PS. Последние версии - это какие? Озвучьте пожалуйста.
По поводу версий - это лучше к AlekSir. Он будет в понедельник, а я больше по "железу" :moil: , в программировании неселен :lam1:
Подключаюсь к разговору коллеги (Scorpio). До этого был в отпуске. :friends:
Так, вот пока я отдыхал. На объекте происходили скачки напряжения и пропадание питания такие что все оборудование технологическое останавливалось. Так вот после восстановления питания все технологическое оборудование перезапустилось без проблем, а вентиляция не заработала. Ошибка - обрыв связи.
Которая организованна c помощью стандартного макроса "Slave (Link)" количество ошибок на входе выставлено 20. Соответственно если с какого-нибудь из блоков "Slave (Link)" приходит break команда, то булева переменная отвечающая за обрыв связи (в нормальном состоянии "1" при обрыве = "0") с мастера передается на Slave останавливающий систему. Плюс ко всему отлавливается обрыв связи между мастером (2G) и этим слевом (2Gi), который останавливает систему т.к. при обрыве связи между ними булева переменная не изменяется в нулевую почему-то, а остается последнее переданное значение.
Так вот обрыв связи отлавливается с помощью двух счетчиков на одном контроллере и на другом сбрасывающих друг друга. Тем самым при обрыве связи счетчик не сбрасывается во время и происходит сигнализация обрыва связи. (но это только между 2G и 2Gi).
А как писал мой коллега система заработала после перепрошивки SMH2010 т.е. обычного слейва и следовательно предполагаем что обрыв связи был вызван именно им.
Для полноты картины дам ссылку на схему сети: http://forum.segnetics.com/showpost.php?p=15505&postcount=12 (во вложении данного сообщения) Единственное уточнение пришлось изменить 2Gi (master) на 2G (master) причину наверное помните, связанна с причудливым логоскрином который мастером отказывался читать данные в формате отличном от 8N1.
Логоскрин связан только с 2G контроллером потому влиять на SMH не должен. Две разных сети на разных com портах думаю не должны влиять друг на друга.
Проблема вылезла только при перепадах напряжения, потому напрашивается вопрос: Может нужно как-нибудь корректно завершать работу сети между контроллерами при перепадах напряжения? Либо при восстановлении питания произвести какой-либо сброс программно?
Связь, как мне передали, восстановилась только после перепрошивки SMH2010 контроллера, потому и всплывают эти вопросы.
По поводу версии прошивки на 2G и 2Gi прошивки одни из самых последних. Не могу найти темку с зависанием клавиатуры при вводе числа в меню, там все было и версии писал и кто-то из специалистов сегнетикса там выкладывал прошивку для тех кто с этим глюком столкнулся. А вот в бескорпусных SMH2010 неизвестно какая версия прошивки и вообще сомневаюсь менялась ли там она с тех пор. Да и с программатором могут возникнуть проблемы. (Его у нас нет)
Связь, как мне передали, восстановилась только после перепрошивки SMH2010 контроллера, потому и всплывают эти вопросы.
Понимаете... Всё бы хорошо, но загрузка программы происходит посредством modbus. Т.е. SMH2010 выступает по отношению к SMLogix слейвом.
В итоге... Если выключение питания не "оживляет" контроллер, то и программу на него загрузить должно быть невозможно. Порт же не работает.
Но если программа загружается, то это означает, что и порт и modbus там рабочие. Т.е. причина более хитрая, чем кажется.
Понимаете... Всё бы хорошо, но загрузка программы происходит посредством modbus. Т.е. SMH2010 выступает по отношению к SMLogix слейвом.
В итоге... Если выключение питания не "оживляет" контроллер, то и программу на него загрузить должно быть невозможно. Порт же не работает.
Но если программа загружается, то это означает, что и порт и modbus там рабочие. Т.е. причина более хитрая, чем кажется.
Понимать то понимаю, потому тут вам и пишу что причина не на поверхности лежит, а скорее всего где-то в железе или логике контроллера.
Возможно это как-то связано с настройками формата передачи данных. Т.к. мы можем менять их программно, так сказать, "на лету". При скачках напряжения, например, проходят какие-нибудь импульсы которые меняют этот формат передачи данных (скорость, четность и т.п.). При заливке программы используется например, какие-то стандартные настройки которые неизменны ни при каких условиях, а вот "общение" с другими контроллерами происходит на изменяемых (пользовательских настройках формата). Может тут собака зарыта?
И еще так и не получил ответа на вопрос о корректном "завершении работы" контроллера при скачках, напряжения. Интересует ответ возможно в принципе что-то подобное или нет. (да/нет) Если да, то может что-то подскажите.
Возможно это...
При скачках напряжения, например...
При заливке программы используется например...
Может тут собака зарыта?
На всё ответ "нет". Особенно применительно к SMH2010.
И еще так и не получил ответа на вопрос о корректном "завершении работы" контроллера при скачках, напряжения. Интересует ответ возможно в принципе что-то подобное или нет. (да/нет) Если да, то может что-то подскажите.
Невозможно рассказать о том, чего несуществует.
Нарисуйте картинку Ваше сети, напишите кто мастер, кто слейв, напишите на картинке настройки портов каждого узла.
Тогда проще (не лень) будет попытаться Вам помочь (а то со слов воссоздавать что у Вас там неохота).
Нарисуйте картинку Ваше сети, напишите кто мастер, кто слейв, напишите на картинке настройки портов каждого узла.
Тогда проще (не лень) будет попытаться Вам помочь (а то со слов воссоздавать что у Вас там неохота).
Вроде все указал и разрисовал.
Связь была нарушена только с одним из слейвов SMH2010 1312. Т.е. данные с него не приходили.
Удалось востановить связь только перепрошивкой именно этого слейва SMH2010.
З.Ы. Перепрошивка производилась через тот же порт, к которому подсоединялся контроллер к сети, по сути заливка была произведенна через сеть 1, а запросы мастера останавливали через системное меню 2G.
Вроде все указал и разрисовал.
З.Ы. Перепрошивка производилась через тот же порт, к которому подсоединялся контроллер к сети, по сути заливка была произведенна через сеть 1, а запросы мастера останавливали через системное меню 2G.
Своё мнение я уже написал. К сожалению, это максимум, который возможно сделать на расстоянии в данной задаче.
Если вы снимете лог работы сети в момент, когда SMH2010 "типа завис", то возможно мы сможем поговорить дальше.
Если вы снимете лог работы сети в момент, когда SMH2010 "типа завис", то возможно мы сможем поговорить дальше.
Встречный вопрос, имеется ли на примете какие-нибудь программки сканеры сети? Желательно freeware и чтоб лог писали.
Я нашел только comread2, но она не free и у нее странное ограничение № com порта не выбирается выше 12-го. И я сомневаюсь, что это ограничение незарегистрированной версии, потому как есть фри-версия (v.1.0), которая тупо дает просматривать что передается в данный момент по сети, и там тоже самое № сом порта не выше 12. :resent:
Встречный вопрос, имеется ли на примете какие-нибудь программки сканеры сети? Желательно freeware и чтоб лог писали.
Я нашел только comread2, но она не free и у нее странное ограничение № com порта не выбирается выше 12-го. И я сомневаюсь, что это ограничение незарегистрированной версии, потому как есть фри-версия (v.1.0), которая тупо дает просматривать что передается в данный момент по сети, и там тоже самое № сом порта не выше 12. :resent:
Portmonitor.exe от микрософта. Вбейте в поиск у них на сайте или в гугле.
Итак, проблема найдена и локализована.
Громко сказано, конечно, но все-таки.
Решение проблемы на прикрепленном скрине. "Вкл.пит." вытащен из макроса обработки аварий - сигнал формирующий сообщение "* Включение питания" в журнале. Собственно после того как этот сигнал вытащил на уставку параметров передачи данных (как показано на прикрепленном файле) проблема решилась.
Из решения проблемы следует и причина потери связи при сбросе питания:
при пропадании питания и появлении его вновь 2G сбрасывает сетевые настройки в настройки по умолчанию или еще какие-то отличные от заданных.
Либо это проблема контроллера и его микросхем либо это проблема макроса "SlaveX". В этом уже должны разбираться Вы - уважаемая техподдержка.
По моему мнению, уставка параметров порта должна задаваться единожды, а не при каждом включении питания.
Со сканом сети, к сожалению не получилось разобраться, думаю потому как пытался работать через конвертор интерфейса, а не на прямую в ком порт, ком порта к сожалению нет на ноуте.
Итак, проблема найдена и локализована.
Техподдержка рапортует:
Блок SlaveX (Link)
Блок SlaveX (Link) обязательно должен быть правильно сконфигурирован, так как стандартные сетевые настройки slave-устройства игнорируются при использовании управляемых slave-запросов. После загрузки и после выключения контроллера до подачи сигнала на вход ^set запросы не отправляются.
http://dl.segnetics.com/WebHelp/SMLogix/slave_prots.htm
Техподдержка рапортует:
Блок SlaveX (Link)
Блок SlaveX (Link) обязательно должен быть правильно сконфигурирован, так как стандартные сетевые настройки slave-устройства игнорируются при использовании управляемых slave-запросов. После загрузки и после выключения контроллера до подачи сигнала на вход ^set запросы не отправляются.
:unsure: Каюсь, не читал.
vBulletin v3.8.7 (Russian), Copyright ©2000-2024, Jelsoft Enterprises Ltd.