[Kitsok 0]

Добрый день!

 

Имеется задача: обеспечить интерфейс между ПО на компьютере и большим количеством дискретных вводов и выводов(около 300 вводов и примерно столько-же выводов), некоторого количества 7-сегментных индикаторов (12 штук по 5 разрядов), небольшим (8) - аналоговых входов, и десятка ШИМов (управление электромоторами).

 

Требования по таймингу - от нажатия на кнопку до срабатывания функции ПО на компьютере - макс. 100 мс, в обратную сторону - то-же.

 

Вокруг бродят магнитные поля от мощных сервоприводов.

Напряжение питания всей сети ввода-вывода - желательно одно, желательно - 12 вольт.

 

Из элементной базы - мне близки AVRы и ARM7 от Atmel, из языка - С, с ассемблером не дружу лет 10, крайний раз писал на нём под х51.

Дискретный ввод-вывод планировал делать цепочками сдвиговых регистров, ШИМ - ШИМом контроллера, аналоговый ввод - АЦП AVRов.

 

Особых требований по стоимости решения нет, поэтому я как буриданов осёл мечусь между IP, RS-232 over IP, RS-485 и вот наткнулся на CAN, а точнее - на чип MCP25050, и стало мне хорошо-хорошо ;)

 

Вопрос такой: где стоит начать читать про CAN, и стоит ли вообще ввязываться в новую тему (как я понимаю, оптимально будет и контроллер использовать микрочиповский, что для меня - вновье).

 

Заранее благодарен!

[firstvald 14]

Смотрите. Чем меньше технологий вы используете, тем больше шансов что справитесь с задачей. Обычный комп обладает только RS выходом. Если у вас есть наработанные отлаженные решения по передаче данных через локальную сеть, ну тогда вперед. Если вы только собираетесь с этим начать работать - это авантюра (ну правда если вам дают год сроку и бабла на это время, то ктож от щиастия повозиться за чужой счет откажется). Обычно подобные системы в промышленности делаются либо по 232 (через мощный драйвер проходит на 9600 и на километр) или на 485. Протокол уж на ваше усмотрение. В промышленности используются символьные и "сырые". В символьном посылки идут так как бы мы их на бумаге нарисовали. Плюс в том, что избыточность символьного протокола служит дополнительным фильтром повышающим надежность, можно понять что передавалось прослушивая линию , ну и просто заглянув в массивы передатчика и приемника. Дополнительный плюс - нечувствительны к временным задержкам. Минусом (с натяжкой) можно считать объем байт передачи. "сырые" передачи - когда гонятся сырые байты. Плюс малый объем передачи , чуть проще декодировать и кодировать посылку. Минус - заглянув в передачу сходу ничего не понятно, признаками окончания посылки является временная пауза (винда очень все это не любит правильно делать).

От себя добавлю, что время обмена вовсе не напрямую зависит от скорости обмена. На скоростях 19200 38400 57600 115200 вам за 100 мс удастся провести 2 цикла обмена с устройством (запросили - оно ответило). Практически не зависими от скорости. Это уже виндовые заморочки.

 

А вообще, судя по вашим задачам посмотрите готовые модули ICP DAS (у них есть и символьные и modbus ("сырые байты") ). (Есть ADAMы - но они в основном под символьный протокол заточены). Все что вы перечислили - уже есть готовое. Вам надо будет только программу на компе написать.

[Kitsok 0]

Спасибо за ответ.

 

Про RS-232. Самый быстрый (и самый при этом дорогой вариант) - внутри объекта наблюдения-управления строится LAN (100Base-T), делается N-модулей, каждый из которых - Mega-что-нибудь, у которой с одной стороны - RS-232, с другой - цепочка регистров ввода-вывода. На RS-232 меги цепляется инкапсулятор в IP, на PC - эмулятор COM-портов на количество портов по количеству модулей, софт получается примитивный. Цена интерфейса - где-то 1000-1500 рублей.

 

Более дешевый вариант - все то-же самое, только вместо LAN внутри объекта - строится сеть RS-485, поверх RS-485 пускаем Modbus и наслаждаемся жизнью.

 

Более интересный вариант - на объекте строится сеть CAN, ставится огромная туча устройств типа MCP2505, на компьютере - приемо-передатчик CAN и разборщик прилетающих сообщений. В этом решении (которое для меня внове) страшно привлекает ненужность контроллеров в модулях, следовательно, меньше вероятность ошибки. Настроили пороги - оно само сообщение отослало если аналоговый сигнал изменился. Нажали кнопку - опять, оно само отослало все что нужно.

 

Также плюсом CANа видится (!) помехозащищенность, большая чем у 485 и уж тем более, чем у 232. По факту, во время работы девайса, профессиональное видеооборудование ловит кучу помех, USB модули ввода-вывода (при помощи которого сейчас реализовано) на лету отваливаются от компьютера, и т.д.

 

Почему не хочу готовое.

Да банально - очень дорого получается, корпуса здоровенный, нам их в объект вставлять некуда, и просто хочется потрахаться ;) Но задача все-таки имеет конечный бюджет и срок (хотя границы их расплывчаты, но они есть ;) ), поэтому хочется понять, откуда начинать и чем все кончится ;)

 

Я сейчас активно занят поиском чего-нибудь а-ля "CAN networks for dummies", поскольку знания мои о шине почерпнуты из даташитов, и весьма поверхностны.

[firstvald 14]

С can не помогу - не знаю. RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

 

USB - зло немерянное. Чего с ним делать ума не приложу. Крпус то компа посередине напряжения питания сети висит через кондюки фильтров в блоке питания - и отсюда куча радости.

[galjoen 0]

Добрый день!

 

Имеется задача: обеспечить интерфейс между ПО на компьютере и большим количеством дискретных вводов и выводов(около 300 вводов и примерно столько-же выводов), некоторого количества 7-сегментных индикаторов (12 штук по 5 разрядов), небольшим (8) - аналоговых входов, и десятка ШИМов (управление электромоторами).

 

Требования по таймингу - от нажатия на кнопку до срабатывания функции ПО на компьютере - макс. 100 мс, в обратную сторону - то-же.

Основная разница между CAN и RS485+модбас в том, что при работе по модбас имеется ведущий, который должен постоянно опрашивать все "а не случилось ли у тебя чего?" и в 99% получать в ответ "у меня всё так же". А CAN подразумевает, что тот у кого случилось к.л. событие сам передаёт в сеть сообщение об этом. Причём событие может быть и сообщение "я жив", "я появился в сети" и т.п., но об этом потом - если вам будет интересно...

В итоге, если в сети 2..3 устройства, то большой разницы между модбас и CAN нет. Но если больше, то в случае модбас время цикла опроса увеличивается пропорционально кол-ву устройств и при формировании модбас на компе при 4-х устройствах уже вы не уложитесь в 100 mS. В случае CAN кол-во устройств сети не имеет значения (до 100 шт.), а имеет значение частота возникновения событий у них. Реально, чтобы гарантировать 100 mS при 125 кбод, и получится порядка 100 устройств в сети. Кроме того в случае CAN легко решается проблемма горячей замены и т.д.

Вобщем выбор зависит от задачи. RS485 - для самых простейших.

 

Есть ещё вариан использовать USART, но с приёмопередатчиками CAN, или с RS485 приёмопередатчиками, но в другом включении - см. автомобильный стандарт J1708. Кстати, для вашей задачи вероятно будет оптимально сделать именно по стандарту J1708/J1587. Всё замечательно работает в жёстких автомобильных условиях... Там получается общая сеть как в CAN, но при использовании USART (собственно CAN из J1708 то и произошёл). И модбасоподобный протокол, но без ведущего (все равноправны). Кстати, не удивлюсь, если модбас тоже оттуда... Но тайминги в J1708 очень жёсткие, поэтому без контроллера не обойтись.

[LV26 0]

RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

 

Странно это как-то.

485 ведь диференциальный....

[mrlee 0]

Преимущество КЭН многие вещи делаются аппаратно. Ну то есть не надо строить обнаружение и поиск ошибок всегда можно узнать доставлен пакет или нет и тд.

Вопрос в том дискретные выводы группами находятся или нет. Ради каждого отдельного дискретного выхода ставить микроконтроллер конечно бред.

Лучше конечно сделать Универсальную небольшую платку на которой есть РС232 (соединение с ПК), Разъем под дискретные входы - выходы это же разъем можно использовать под индикатор.

Я изучал кэн сразу с пдф-а микросхемы все в принципе понятно, но правда протоколы высокого уровня не ставил.

Проверял работу в условиях достаточно сложных помех (высоковольтные испытания с пробоями) - претензий нет.

[syoma 1]

Если стоимость не имеет значения а изделие штучное, то может стоить попробовать что-нибудь на базе Ethernet - например EtherCat. Готовые модули под Ваши задачи имеются.

[galjoen 0]

Также плюсом CANа видится (!) помехозащищенность, большая чем у 485 и уж тем более, чем у 232. По факту, во время работы девайса, профессиональное видеооборудование ловит кучу помех, USB модули ввода-вывода (при помощи которого сейчас реализовано) на лету отваливаются от компьютера, и т.д.

По помехозащищённости CAN и RS485 примерно одинаковы (RS485 чуть-чуть лучше). А говорить про помехозащищённость RS232 вообще смешно...

Но в случае CAN самый низкий уровень (или 2 самых низких?) передачи обеспечивается аппаратно, а на RS485 нужно делать ручками. Но в реальности это делается легко...

 

Нормально сделанная USB девайсина после отваливания из-за помех, сама по новой прицепится. Ну или программа на компе может её переприцепить. Только это опять же - ручками делается.

Я сейчас активно занят поиском чего-нибудь а-ля "CAN networks for dummies", поскольку знания мои о шине почерпнуты из даташитов, и весьма поверхностны.

А вообще, вам было бы лучше эту тему в разделе "интерфейсы для начинающих" поместить. Там вам лучше посоветуют. Обратитесь к модератору - попросите перенести...

[rezident 0]

RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

А условия эксперимента можете огласить? Видимо все по стандарту при этом было: 19200bps по RS232 на 12м и 115200bps по RS485 на 1000м? Или как?

[Kitsok 0]

Спасибо за отклик ;)

 

Насчет multidrop RS-232 - я смотрел, не нравится, какой-то не шибко стандартный и непонятно как работающий вариант.

 

По прочтении даташитов и всяческих примеров, вырисовывается такая картина: есть контроллер, с одной стороны у него IP (не особо важно, RS-232 over IP или голые пакетики), с другой - несколько MCP2515+MCP2551 на SPI. К каждому MCP2551 подцеплена своя ветка шины (из соображений количества буферов приема-передачи, хотя я пока чушь несу, недочитал). Это у нас получается мастер. Его задача - принять данные от компа, разобрать их по узлам назначения и отправить. Принять от узлов сообщения, разобрать-собрать и передать в комп.

 

Периферийные узлы - либо та-же Мега + MCP2515+MCP2551 + (упс) цепочка регистров ввода-вывода на кнопочки-лампочки-концевички, либо MCP2505. Во втором случае количество периферийных узлов стремится в космос ;)

 

А можно ли (предусмотрено ли стандартом) "попросить" периферийный узел прислать состояние всех своих входов-выходов? Ну например, в целях синхронизации, раз в пару секунд передавать в PC актуальное состояние всех входов?

[syoma 1]

А можно ли (предусмотрено ли стандартом) "попросить" периферийный узел прислать состояние всех своих входов-выходов? Ну например, в целях синхронизации, раз в пару секунд передавать в PC актуальное состояние всех входов?

"Попросить" всегда можно. MCP2505Х в таком режиме тоже работает. Также ее можно настроить, чтобы она автоматически сама посылала периодически состояние своих входов.

[firstvald 14]

бухта в 1000 метров с резюками на концах. И гоняем команды. Смотрим ошибки. Рядом ставим искровую помеху. Сравниваем. Влом уже смотреть до каких скоростей поднимался - неск лет назад было, но 19200 точно. Но только сравниваем на своих приемопередатчиках. В 485 это, правда, всегда какая-нибудь adm.

 

485 то дифференциальный, но порог у него порядка 200 милливольт, а 232 по-моему 2-3 вольта. Вот и разница. А на практике в

485 куча спецэффектов всяких, вот сижу думку гадаю, почем у в нем не все так замечательно, как могло бы казаться.

Вообще, то что вижу на практике - 485 очень ненадежно. Может заработать, а может и нет.

Очень коротко:умощненный 232 заработает сразу, 485 - все будет что-то не совсем так, потом может заработает. Там, кстати, не обращали внимание? , что 485 3 проводный (хотя в промышленности кто-то это выполняет, а кто-то нет)? А то я, как первый раз прочитал - ооочень удивился, оказывается документацию надо читать.

[Kitsok 0]

Добрый день!

 

Последние дни читал и даташит на AT90CAN, и исходники всевозможные (в особенности мне понравилось вот это: http://kschaefer.eit.h-da.de/ATMEL/CAN/index.html ), поэтому вопросы, наверное, будут теперь более осмысленные.

 

Читаю документец про сеть на борту наноспутника (http://etd.sun.ac.za/handle/10019/858 ) и удивляюсь: они выстроили протокол над CAN-контроллером, где имеют место быть квитанции (ACK).

 

Вопрос: а зачем это надо? Плюнули пакет в сеть, по идее механизм разрешения коллизий и технично настроенный таймаут передачи гарантирует доставку пакета в сеть, или я не прав?

 

Вот еще вопрос про физическую топологию. Хочу в один кабель запхать и CAN, и питание. Тянуть чистую "шину" не получается, "звезда" в моем случае оптимальна. Т.е. есть плата-дистрибьютор с кучей разъемов, например, DB-9. Максимальное расстояние от дистрибьютора до узла - метра три. Вопрос - а где ставить терминаторы?

[AlexandrY 3]

CAN самая надежная, дешевая и простая технология.

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

Уже много систем реализовал на CAN. Один из них - ПОЛИГОН

Практически по скорости разработки CAN-у нет равных.

На скорость влияет прежде всего наличие софта готового и хорошо документированного.

На этот счет лучше всего поддержаны контроллеры от NXP и ST.

На втором месте по влиянию на скорость разработки стоит удобство отладки.

Здесь вне конкуренции чипы на ядре Cortex-M3.

Поэтому останавливаем свой выбор на STM32xxxx или LPC17xx

Скажем выбираем STM32F103ZE

Имеет надежный CAN контроллер. Отладка по JTAG с просмотром состояний любых переменных в реальном времени без остановки программы!

Куча примеров в средах разработки Keil и IAR. В Keil есть даже специальная библиотека работы по CAN и очень удобный диалоговый конфигуратор.

Для узлов с количеством сигналов более 8-и ставлю контроллер из линейки STM32F103. Где сигналов меньше ставлю из линейки MCP2502x.

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

Это прежде всего аппаратный CRC, безконфликтный арбитраж, самодиагностика, автоповторы, автоматические тайминги и т.д.

Скажем у нас в реальных условиях CAN работал даже когда некоторые узлы по ошибке были включены инверсно, когда насекомые объедали изоляцию и провода висели в сырости голые, когда сбоили и пытались передать мусор некоторые дивайсы в сети, когда применяли на длинных участках несогласованный кабель, когда рядом лежал силовой кабель 220 и т.д.