DmitrijStepin 0 12 ноября, 2013 Опубликовано 12 ноября, 2013 · Жалоба Здравствуйте! Есть необходимость сохранения передачи данных в шине RS485 при обрыве кабеля или коротком замыкании. Допустим, если на каком-то сегменте произошло короткое замыкание, то этот сегмент нужно отключить от остальной шины. Но другие модули, которые следуют за поврежденным участком, не должны отключиться от главного опрашивающего устройсва (Master). Для этого рассматриваю использование замкнутой петли. На Мастер плате предусмотрено использование двух портов. Один порт является началом шины, а второй - концом. Если данные не приходят с Slave модулей по одной шине в случае какой-либо неисправности, то эти модули начинают опрашиваться по второму порту. Хочу узнать, является ли такое решение рациональным и самым простым. Так по идее даже возможно увеличить длину шины. Использование только одного порта для создания замкнутой петли не годится. Так? Какие устройства используются в качестве детекторов короткого замыкания в шине RS485. Слышал, что такие есть, но не приходилось использовать их раньше. Возможно, сможете посоветовать что-то еще. По крайней по такому принципу делают системы. С уважением, Дмитрий Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vladec 12 13 ноября, 2013 Опубликовано 13 ноября, 2013 · Жалоба По моему, Вам проще быдет просто проложить две отдельных шины основную и резервную и при аварии на одной можно будет работать по другой, как, например, в стандарте MIL1553 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mr.G 0 13 ноября, 2013 Опубликовано 13 ноября, 2013 (изменено) · Жалоба По моему, Вам проще быдет просто проложить две отдельных шины основную и резервную и при аварии на одной можно будет работать по другой, как, например, в стандарте MIL1553 Согласен. Резервная может показать какой slave вышел из строя, отключаем его и далее снова работаем по основной. А по поводу опознавания КЗ, наверное нужно поискать соответствующие микросхемы с реализованной данной функцией, Maxim и TI вам в помощь. Изменено 13 ноября, 2013 пользователем mr. G Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 13 ноября, 2013 Опубликовано 13 ноября, 2013 · Жалоба Возможно, сможете посоветовать что-то еще. По крайней по такому принципу делают системы. А почему не CAN? Решал сходную задачу для поездов. Только там не кольцо, а "паравоз" из контроллеров. Важно было определять скорее не КЗ и Обрыв (это легко определается), а последовательность включения контроллеров. Т.е. вагоны можно как угодно перецеплять, но система автоматически знает, что авария произошла в пятом вагоне от головы, например. При КЗ и обрывах, можно узнать между какими контроллерами неисправен сегмент и выключить его из работы. Работоспособность системы от головы до "дохлого" сегмента восстанавливается, а что за "дохлым сегментом" происходит неизвестно (но там есть вторая голова, которая может вести протоколирование аварий, но не в оповещать в реалтайме). Да, придется повозится с пакетами, т.к. CAN это максимум 8 байтв пакете, но побочно получаете "кучу плюшек" самая ценная из них мультимастер! Менее ценные: запрет включенного зависшего передатчика, счетчики ошибок и автоматическое отключение от шины при их прерышении и т.п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitrijStepin 0 14 ноября, 2013 Опубликовано 14 ноября, 2013 · Жалоба По моему, Вам проще быдет просто проложить две отдельных шины основную и резервную и при аварии на одной можно будет работать по другой, как, например, в стандарте MIL1553 Две линии тянуть не хотелось бы из-за высокой стоимости проводов, т.к. данная система используется в противопожарных системах. По нормам нужно использовать огнестойкие кабеля. Вами предлагаемый подход предусматривает использование двух портов на каждом модуле: один для основной шины, а второй - для резервной? Согласен. Резервная может показать какой slave вышел из строя, отключаем его и далее снова работаем по основной. А по поводу опознавания КЗ, наверное нужно поискать соответствующие микросхемы с реализованной данной функцией, Maxim и TI вам в помощь. Отключать модули от Мастер модуля нельзя при обнаружении неисправности кабеля. Они должны оставаться в системе. Принцип должен быть такой: если в "основном" пути для некоторых модулей обнаружена неисправность кабеля, то они начинают опрашиваться по "резервному" пути. Повреждение основной линии должно быть устранено по возможности быстрее. По идее в нормальном режиме работы нужно опрашивать модули как по основной шине, так и по резервной поочередно, чтобы не получилось так, что при переключении на резервную шину она не была неисправной тоже. А почему не CAN? Решал сходную задачу для поездов. Только там не кольцо, а "паравоз" из контроллеров. Важно было определять скорее не КЗ и Обрыв (это легко определается), а последовательность включения контроллеров. Т.е. вагоны можно как угодно перецеплять, но система автоматически знает, что авария произошла в пятом вагоне от головы, например. При КЗ и обрывах, можно узнать между какими контроллерами неисправен сегмент и выключить его из работы. Работоспособность системы от головы до "дохлого" сегмента восстанавливается, а что за "дохлым сегментом" происходит неизвестно (но там есть вторая голова, которая может вести протоколирование аварий, но не в оповещать в реалтайме). Да, придется повозится с пакетами, т.к. CAN это максимум 8 байтв пакете, но побочно получаете "кучу плюшек" самая ценная из них мультимастер! Менее ценные: запрет включенного зависшего передатчика, счетчики ошибок и автоматическое отключение от шины при их прерышении и т.п. По мере усложнения системы все больше склоняюсь к использованию CAN вместо RS485. Но это только планы на будущее. Сейчас использую RS485. Использование CAN не решит данную проблему. Для CAN и RS485 подход к решению этой проблемы должен быть похожий. Система должна оставаться всегда реального времени, потому что по нормам в противопожарных применениях максимальное время определения тех или иных событий в системе не должно превышать одну минуту. Каким образом отключается неисправный сегмент при обнаружении КЗ или обрыва? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 14 ноября, 2013 Опубликовано 14 ноября, 2013 · Жалоба По мере усложнения системы все больше склоняюсь к использованию CAN вместо RS485. Но это только планы на будущее. Сейчас использую RS485. Использование CAN не решит данную проблему. Для CAN и RS485 подход к решению этой проблемы должен быть похожий. Система должна оставаться всегда реального времени, потому что по нормам в противопожарных применениях максимальное время определения тех или иных событий в системе не должно превышать одну минуту. Так я Вам и описал охранно-пожарную систему для поезда. А требование в одну минуту там звучит еще жестче: за 20 секунд надо не только получить сигнал от датчика и обрабоать на ложные сработки, но и начать передавать речевое сообщение диспетчеру по радиостанции. Каким образом отключается неисправный сегмент при обнаружении КЗ или обрыва? Механически при помощи реле. В нормальном состоянии реле распитано и все сидят на одной линии. Если есть авария в сегменте, то обмен по шине не возможен, ни одно сообщение не может быть отправлено, по истечении таймаута все контроллеры размыкают свои реле и начинают тестировать "левый" и "правый" сегменты на исправность. Если оба сегмента исправны, то реле у данного контроллера распитывается, и левый и правый сегменты превращаются в единное целое. В итоге при одном неисправном сегменте будет по контроллеру слева и справа с запитанным реле - сегмент локалирован. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 14 ноября, 2013 Опубликовано 14 ноября, 2013 · Жалоба Т.е. вагоны можно как угодно перецеплять, но система автоматически знает, что авария произошла в пятом вагоне от головы, например.Можно об это подробнее. (можно в личку) За счёт чего удаётся определить очерёдность подключения вагонов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 14 ноября, 2013 Опубликовано 14 ноября, 2013 · Жалоба Можно об это подробнее.... +1 так-же отметил интерес к решению, данного вопроса. Если не затруднит(и нет секретов) - отпишите прямо на форуме. Думаю многим будет и интересно, и наколка на будущее - с кем можно пообщаться по данному вопросу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 14 ноября, 2013 Опубликовано 14 ноября, 2013 · Жалоба так-же отметил интерес к решению, данного вопроса. Если не затруднит(и нет секретов) - отпишите прямо на форуме. Думаю многим будет и интересно, и наколка на будущее - с кем можно пообщаться по данному вопросу. Секрет, думаю, есть, и он должен остаться у правообладателя - компании, где я уже сейчас не работаю, но разрабатывал, будучи ее сотрудником. Если без особых подробностей, то есть единная шина, к которой контроллеры цепляются не совсем как к шине: на самом деле есть "левый" и "правый" входы в изделие и они в топологии не должны быть замкнуты, т.е. "левый" вход контроллера должен идти к, например, предыдущему элементу сцепки, "правый", соответственно, к следующему элементу. В нормальном состоянии "левый" и "правый" входы физически соединяются (реле) в контроллере и к ним подключается сам интерфейс контроллера. В некоторые моменты, при так называемой "автонумерации" шина распадается на сегменты, путем размыкания реле всех контроллеров - определить последовательность в этом случае дело техники (но я смог этого добится только для CAN, на RS485 не уверен, что можно реализовать). При отстутсвии пакетов на шине в течении определенного времени, нужно опять "развалиться" на отдельные сегменты - вероятно есть авария на шине (чаще всего КЗ). Подводных камней - вагон и маленькая тележка (с таймаутами сплошная магия). Подробности, думаю, уже не могу обсуждать. Все что перечислил выше, вряд ли можно считать тайной, т.к. есть в описании системы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitrijStepin 0 18 ноября, 2013 Опубликовано 18 ноября, 2013 · Жалоба Секрет, думаю, есть, и он должен остаться у правообладателя - компании, где я уже сейчас не работаю, но разрабатывал, будучи ее сотрудником. Если без особых подробностей, то есть единная шина, к которой контроллеры цепляются не совсем как к шине: на самом деле есть "левый" и "правый" входы в изделие и они в топологии не должны быть замкнуты, т.е. "левый" вход контроллера должен идти к, например, предыдущему элементу сцепки, "правый", соответственно, к следующему элементу. В нормальном состоянии "левый" и "правый" входы физически соединяются (реле) в контроллере и к ним подключается сам интерфейс контроллера. В некоторые моменты, при так называемой "автонумерации" шина распадается на сегменты, путем размыкания реле всех контроллеров - определить последовательность в этом случае дело техники (но я смог этого добится только для CAN, на RS485 не уверен, что можно реализовать). При отстутсвии пакетов на шине в течении определенного времени, нужно опять "развалиться" на отдельные сегменты - вероятно есть авария на шине (чаще всего КЗ). Подводных камней - вагон и маленькая тележка (с таймаутами сплошная магия). Подробности, думаю, уже не могу обсуждать. Все что перечислил выше, вряд ли можно считать тайной, т.к. есть в описании системы. Идея понятна. Спасибо за краткое описание. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
