2 проткола, в одной сети RS-485 Опции

[Demus]

Здравствуйте.

Пожалели денег на кабель или не продумали заранее. Но теперь на одной шине счетчики меркурий с протколом Меркурий и ПЛК с модбасом. Будут дружить или все плохо? Мастером выступает ПК с Trace Mode

[Demus]

Здравствуйте.

Пожалели денег на кабель или не продумали заранее. Но теперь на одной шине счетчики меркурий с протколом Меркурий и ПЛК с модбасом. Будут дружить или все плохо? Мастером выступает ПК с Trace Mode

[CS602]

раздельно (не одновременно) работать должны, а одновременно - ... покажет только эксперемент (хотя скорее всего при одновременных запросах будут копфликты).

[cauto]

Но теперь на одной шине счетчики меркурий с протколом Меркурий и ПЛК с модбасом.

Как вариант: примочка для Меркурия от Тракта (Меркурий-Модбас).

[AlexG]

Протоколы Меркурий и Модбас могли бы жить в одной шине. Они довольно похожи и конфликтов из-за реакции устройств на чужие пакеты возникать не должно. Но как вы Трейсмоду объясните что на одном интерфейсе надо использовать два протокола? Преобразователь протокола счетчиков в модбас от Тракта очень хороший вариант в такой ситуации.

[shylock]

Но как вы Трейсмоду объясните что на одном интерфейсе надо использовать два протокола?

Почему обязательно на одном? Каждому протоколу свой COM-порт, и оба к одной RS-485 линии.

[VadimNN]

Почему обязательно на одном? Каждому протоколу свой COM-порт, и оба к одной RS-485 линии.

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

Сообщение отредактировал VadimNN - 12.12.2012, 12:23

[Demus]

Но как вы Трейсмоду объясните что на одном интерфейсе надо использовать два протокола? Преобразователь протокола счетчиков в модбас от Тракта очень хороший вариант в такой ситуации.

А зечем ему объяснять? Там струтура такая. Есть каналы. Они привязываются к источникам приемникам. Источник -приемник отвечает за нужный Com порт и протокол. В одно время выполняется только один канал. Это вот на пальцах как я понимаю. По идее со стороны мастера не должно быть проблем. А вот слейвы...

К сожалению описание протокола Меркурий найти не могу, а разработчик высылает только по письменному запросу организации. А я на объекте почти живу) Поэтому если у кого есть протокол поделитесь в личку. Хотя бы посмотреть начало посылки. Возможно подберу адреса модбас устройств, чтобы начала посылок не совпадали (там где адрес и команда в модбасе). Ну и интересно для чего у меркурия организовано открытие сеанса обмена с пересылкой пароля, а потом только запрос данных.


Новый кабель проложить нереально. Торговый центр длинной несколько сот метров. Зашито гипсокртоном и прочие прелести.

[VadimNN]

Напротив, я думаю проблемы как раз с мастером. Во-первых, насколько я помню, при конфигурировании порта в ТМ необходимо указывать его назначение. Для меркурия это будет обмен через универсальный драйвер электросчетчиков, соответственно назначение порта будет E-meter, для модбаса будет что-то другое. И разве можно ли в ТМ сконфигурировать один порт на два протокола? К сожалению сейчас у меня нет возможности проверить. Во-вторых в ТМ весь обмен скрыт от пользователя и как данные приходят в канал не известно. По вашему мастер сначала дает запрос, потом получает ответ, потом запрос по следующему протоколу, получение ответа. Но может быть и совсем не так. Например ТМ может сначала выдавать запросы по всем портам, и ждать ответов. В таком случае разобрать где какие запросы и ответы невозможно.

Протокол Меркурия отправил. Пересылка пароля видимо для того, чтобы вы не "скрутили" счетчик программно

Сообщение отредактировал VadimNN - 13.12.2012, 7:38

[shylock]

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

Я бы никак не обрабатывал, игнорировал. Если скорость достаточно высокая, и данные считывать редко, то коллизий будет немного.

С конкретно этой скадой не работал, так что не знаю, можно ли её настроить на режим "игнорирования".

[VadimNN]

Я бы никак не обрабатывал, игнорировал. Если скорость достаточно высокая, и данные считывать редко, то коллизий будет немного.

С конкретно этой скадой не работал, так что не знаю, можно ли её настроить на режим "игнорирования".

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

А может попробовать производить опрос по разным портам на разных скоростях передачи? Для меркурия 9600, а для контроллера например 115200бит/с.

[MDiv]

Так может поставить разное время обработки канала, чтоб конфликтов не возникало?

[Demus]

Так может поставить разное время обработки канала, чтоб конфликтов не возникало?

В настройках канала там ставится периодичность вызова канала. Но программно могу конечно разделить по времени обращение к ком порту тем или иным каналам. Хорошая мысль.

Тем временем добрался до двух счетчиков.Они с can. Не хватает 5В для запитки. Скоро буду пробовать. При чем CAN преобразовывать не буду в RS-485. Вот так планирую http://incotex-counter.blogspot.ru/2011/03/can-rs485.html

[VadimNN]

Вы хотите совместить modbus и CAN на одной шине? Это новое слово в науке и технике! Обязательно отпишитесь про результат.
Для справки: в трейсмод универсальный драйвер электросчетчика не поддерживает шину CAN.

[shylock]

В трейсмод настроить игнорирование нельзя, а что есть скады где можно? Но ошибочные кадры и так должны игнорироваться.

Под "игнорированием" подразумевается то, как скада реагирует на ошибки на линии. Если просто показывает последнее корректно считанное значение и потом продолжает его запрашивать в штатном режиме -- то от пользователя коллизии будут скрыты. Что и требуется.

Но разумеется, если счётчики CAN, то ничего работать не будет

[shylock]

Прочитал статью про преобразователь 485/CAN на резисторах -- беру свои слова назад. Может и будет работать!

[Demus]

первая попытка не удалась. Прбовоал из их родного конфигуратора. Без подтягивающих. Просто был терминальный резистор 120 Ом.

[kav1]

Тыща р. за штуку... Вот таких OPC я ещё не видал... Зато оптом скидка.... ППЦ

Сообщение отредактировал kav1 - 17.12.2012, 21:47

[san]

Вы хотите совместить modbus и CAN на одной шине? Это новое слово в науке и технике! Обязательно отпишитесь про результат.

CAN - CANу рознь. BOSH CAN не описывает физику передачи. Так что гипотетически CAN-чип можно привязать (и наверное привязывали) к приемопередатчику 485-го, если 485-е передатчики при 0 и 1 будут давать на шине четкий логичкий доминатный сигнал.

[VadimNN]

CAN - CANу рознь. BOSH CAN не описывает физику передачи. Так что гипотетически CAN-чип можно привязать (и наверное привязывали) к приемопередатчику 485-го, если 485-е передатчики при 0 и 1 будут давать на шине четкий логичкий доминатный сигнал.

BOSH CAN как раз описывает физику и кроме того метод доступа к среде передачи http://www.canopen.org/index.php?id=system...n-physicallayer
По RS-485 протоколы работают в режиме Мастер-слейв, в CAN с распознаванием коллизий, эти шины имеют различные длины кадров и их структуру. Каким образом их можно совместить на одной линии? Гипотетически только разнеся периоды передачи, но практически это не получится, т.к. чип может независимо от пользователя обращаться к линии.

[Demus]

Да, пока не удалось по Rs-485 связаться. Позвонил в тракт автоматику запросил счет на их железки из can меркурий в rs-485 modbus. Видимо придется ждать из Томска их ноу-хау.

[san]

BOSH CAN как раз описывает физику и кроме того метод доступа к среде передачи

Прочитайте внимательно свою же ссылку. BOSH CAN описывает только канальный уровень (где и решается метод доступа) и ЧАСТЬ физического касаетльно требований к синхронизации бит на физическом уровне и наличии домниантных и рецессиввных битов. А вот например ISO 11898 (который включает уровни CAN) уже описывает уровни напряжения при передаче, количество узлов, длины и т.д.

[VadimNN]

Прочитайте внимательно свою же ссылку. BOSH CAN описывает только канальный уровень (где и решается метод доступа) и ЧАСТЬ физического касаетльно требований к синхронизации бит на физическом уровне и наличии домниантных и рецессиввных битов. А вот например ISO 11898 (который включает уровни CAN) уже описывает уровни напряжения при передаче, количество узлов, длины и т.д.

Согласен, тип линии передачи там не определен. Но в данном случае не тип линии мешает совместить RS-485 и CAN, а как раз эта часть физического уровня касающаяся доминантных и рецессивных бит в CAN.