dormouse

Есть 7-ми проводной двунаправленный логический интрерфейс. надо его размыкать и "брать на себя". как это правильно сделать при маленьком объёме (без механики и реле, разумеется)? Конкретнее: Устройство А использует сменные части В. задача: разобрать один из В и смонтировать его электронику внутрь А. Подключать при необходимости вместо внешнего В. Проблема - Когда подключен внешний настоящий В надо отключать внутренний.

Продолжаю разбираться с CiA 301. Меня смутил порядок следования полей. Основные варианты: либо A: 1. P бит - ID посылающего => уже работает арбитраж 2. дальше уже неважно, поскольку один может "за раз" послать только 1 сообщение либо B: 1. Код сообщения => первичный арбитраж по "важности" сообщения 2. ID посылающего => вторичный арбитраж по приоритету источника 3. ID приёмника - уже только для фильтрации на стороне приёмника, не участвует в арбитраже, как и п. А.2. либо С: (для неравновесной системы [в смысле 3 мастера, 10 слейвов]) 1. Указание мастер/слейв (или большее число групп) 2. Код 3. Оставшаяся часть ID посылающего 4. ID приёмника Похоже, что реализован вариант B, поскольку предполагается, что сами по себе функциональные коды делятся на коды, возможные для 1 мастера и на коды, общие для группы слейвов (B = C при 1 мастере). Я правильно понял суть? Если действовать в рамках стандарта CANOpen, фактически надо реализовать часть обязательных функций от CANOpen slave, а работу на PC в качестве мастера исполняет купленная за деньги .dll на их аппаратной платформе?

Все-таки решительно надо иметь земляной провод в идеологии RS-485. Это не вполне очевидно, поскольку есть много примеров дифф. линий, в которых нет "земляного" провода. В 4-х проводном варианте земля тоже одна. Если продолжать "правильный идеологически" разговор, то RS-485 привязан к конкретной физической реализации. CAN оперирует понятием "доминантного и рецессивного" битов, что без проблем имплементируется оптоволокном ("один проводок"). Сигнал (световой импульс) либо есть = "доминантный", либо нет. Использование электрического способа передачи данных для CAN - это одна из многих (гипотетически) реализаций, не являющаяся "единственно правильной" или "плохой, но работающей".... to: spf. Прочёл внимательно первый пост в этой теме. Еёсли речь идёт о CAN 2.0A, то получается интересная арифметика: "Разделим CANID(11бит) на 3 секции : 5+4+4" =13 в сумме, как я понимаю? . Пока не довёл до конца изучение CiA 301, но уже подчерпнул много полезного. Раздел с определением полей внутри CANID пока не смотрел, поэтому не могу говорить на тему реализованного количества поддерживаемых устройств. Спасибо за указание на стандарт.

"Если сравнивать RS-485 c CAN" - то это на самом деле сравнения яйца с курицей. Сравнение возможно только поле того, как разберёшься в том, что такое "CAN"... После этого пункта само слово "сравнение" будет трактоваться уже иначе. Важно понять, что RS-485 без использования MODBUS или чего-то подобного есть просто "три проводка", которые соединяют аппаратные UART на двух (или более) MCU. Отличие только в несравнимо больших расстояниях и помехозащищённости. Ничего нового это не добавляет в плане качества связи, гарантированности доставки или чего-либо ещё. Это только ХОРОШИЙ способ растянуть три проводка на N метров. С CAN ситуация обратная всвязи с добавлением второго уровня OSI - для программы это такой же "чёрный ящик", как и UART: 1. MSG-> bbox 2. bbox->[по шине]->bbox1, bbox2...bboxN 3. у bbox2 во время приёма возникла ошибка (он засомневался) => опять на шаг 2 *Обращаем внимание, что не на шаг 1!* 4. [раз здесь, то послали, или знаем, что не послали] UART принципиально имеет MSG=1байт, при этом у него НЕТ средств для аппаратной реализации шагов 2 и 3. !! Уже писал в свой топик. Сюда же дублирую: ---------------------------------------------------------------- Atmel сделала шаг вперёд к gcc и CAN. Конкретно: только что выложили новую версию библиотеки для At90CANxxx для gcc! Качаем, разбираемся. Похоже, что внутри уже имеются примеры работчего "скелета" программ hello world для работы с шиной. http://www.atmel.com/dyn/products/product_...sp?part_id=3780 ----------------------------------------------------------------- !!

Atmel сделала шаг вперёд к gcc и CAN. Конкретно: только что выложили новую версию библиотеки для At90CANxxx для gcc! Качаем, разбираемся. Похоже, что внутри уже имеются примеры работчего "скелета" программ hello world для работы с шиной. http://www.atmel.com/dyn/products/product_...sp?part_id=3780

Цена действительно оказалась более чем приемлемой. Я полагал примерно 2x-4x диапазон. При этом раскладе это <$1500 для начала работы, что приемлимо даже для личной разработки. Осталось разобраться в следующем: физически CANOpen - это только data frame, которые ходят по шине. Никакая конкретика непосредственной физической реализации аппаратного уровня его не интересуют. Из этого можно сделать вывод, что и код на C должен быть одинаковым как для PC карты, так и для MCU. У них же (если я правильно понимаю) предлагается отдельно "стандарт" и отдельно "он же реализованный под Win32 с закрытым кодом", отдельно "софт мониторирования пакетов и проверки соответствия работы устройства стандарту", ну и платы, разумееется. Если внимательно посмотреть на это, то вместо их библиотеки можно было бы использовать C версию кода, но они его не предоставляю. Я правильно понимаю ситуацию, что фактически надо реализовать 80% их библиотеки, являющейся кросс-платформенной, в каждом проекте? Нешёл очень интересный сайт с большим чилом БЕСПЛАТНОГО софта (ограниченного на 125к/бит и временем работы), называется port.de. http://www.port.de/engl/canprod/content/software.html Пока не ясно, но возможно, что предлагают недорогую кросс-платформенную реализацию на С.

Тогда можно попросить указать цены на вами закупленное решение: 1. Цена на плату, на библиотеку, на документацию (примерно до +- 50$). Сайт datamicro оказался очень сложен в использовании :-) В нашем случае вроде нет необходимости делать стыковку с приборами не своего изготовления, поскольку они "по сути" не применимы в данном случае. Скорее всего это будет сделано при переходе на "следующий" виток развития, если вообще будет сделано. На данном этапе скорее всего будет доделана работа с CAN на основе At90CAN128 (примерно шесть экземпляров на одну систему), сбор данных температуры и прочего осуществляется по Dallas 1-wire, а самый дешёвый датчик с CANOpen стоил почти 800euro, что пока излишне ;-) В качестве USB-PC будет устройство от slavna.ru - они предоставляют "каркас" программы на VC, так что можно очень быстро начать его использовать, поскольку код на C портируется с MCU без изменений, только интерфейсная часть будет другой.

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути: 1. Иметь МНОГО времени и реализовать либо свой CANOpen 2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников) 3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его. 4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом". Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

Позволю добавить от себя ;-) Я разобрался с работой CAN за неделю. Из своего непонимания почти всё было ликвидировано. Вопрос о негарантированности доставки одному из слейвов (получателей) приобрёл другой характер: CAN шина ГАРАНТИРУЕТ, что все приёмники РАБОТАЮЩИЕ В ЭТОТ МОМЕНТ на шине успешно получили сообщение. Никакой информации о количестве узлов, получивших сообщение НЕТ! В контексте поего предыдущего вопроса из этого можно сделать вывод, что надо после этого уметь на мастер узле принять N подтверждений о доставке (узел мог просто потерять питание!). В противном случае надо принять решение о дальнейшей работе всех устройств. Сложность реализации оказалась незначительной, но до конца я пока не разобрался ( скажем, как надо распределить MOB'ы если посылающий RDF должен принять ответ на него и прочие мелочи), поскольку в данный момент после успешного испытания простейшего решения на базе "один сообщил => другой принял" работы ведутся над другими частями. PS Отдельное спасибо НПП Славна (http://www.slavna.ru). Успешно получено купленное у них USB->CAN устройство. Пока не испытано.

Вроде разобрался. Текущее понимание: 1. Есть 2 корпуса для одного УГО с одинаковой нумерацией ног 1 УГО + 2 альтернативных footprint'a 2. Есть 2 разных по числу ног или расстановке ног корпуса 2 пары (УГО1,КОРПУС1), (УГО2,Корпус2) 3. Есть 1 корпус с несколькими [N=P+Q] элементами внутри (неважно Pштук homo/Qштук hetero) N штук УГО рисуются "на общих основаниях" в N окошках Package. Номера ног расставляются согласно корпусу. --------------------------------------------------------- Если надо сделать, скажем макетный кусок на плате, это правильный подход? : 1. Размещаем 200 pin в layout'e (Library Manager) 2. Соединяем Obstacle'ом "free track" на слоях top и bot [предположение, что 2-х сторонняя без внутренних слоёв) 3. шины земли и питания макета подключаем к ногам GND (1,3) Vcc (2,4) Сохраняем footprint "maket" 4. Делаем компонент в Capture: homogen, 1 per PKG, 4 ноги, соединяем их с GND и Vcc, footprint: maket 5. Сохраняем УГО "maket". Capture ругнётся, что Duplicate name GND, но сохранит. Про Vcc не спросит. Вставляем и пользуемся? Никаких проблем?

Раньше не требовалось, сейчас необходимо. Постановка задачи: один раз нарисовал T0-92, в схеме несколько разных утройств в таком корпусе (скажем 2 транзистора, один термометр и 78l05). Есть ли в OrCAD _ВООБЩЕ_ промежуточная таблица соответствия между ногами в УГО и номерами/названиями в footprint'e LibraryManager'a. Конкретнее: можно задать все УГО с ногами 1-2-3 и присвоить им имена согласно назначению. После этого я вижу только одно место - поле PCB Footprint, которое получает только "TO-92". В таком раскладе надо либо сразу создавать УГО с правильной последовательностью ног (что противоречит возможность иметь хотя бы 2 разных корпуса для одного УГО), либо иметь промежуточную таблицу соответсвия. Пример: УГО N | УГО Name TRANSLATION | Footprint 1 | E ................. 3 | 1 2 | C ................ 2 | 2 // Нога УГО.1 переходит в ногу footprint.3 3 | B ................ 1 | 3 Альтернатива - рисовать [(Число ног)Факториал] разных корпусов, различающихся только порядком нумерации ног. ------------- Дальше. У одного элемента есть 2 реализации, скажем первая в SO, вторая в DIP. Различия не только в номерах ног, но и в количестве NC ног (в DIP на 2 больше). Как правильно сделать такой элемент? А если в DIP будет не один гейт, а 2 (homogenius) вместо 1 у SO? ----------------------------------------------- На данном этапе я подозреваю, что придётся рисовать по одному УГО на каждый тип корпуса, в качестве PIN Name указывать настоящее название, а PIN Number согласно номеру этой ноги в данном конкретном корпусе (при этом совершенно неясно как быть с многогейтовостью). ------------------------------------------------------------------------- Подитожить можно опять повтором описаня темы: "в УГО компонента только имена, на PCB - только номера. В середине - таблица соответствия". Это решает и проблемы мультигейтовости и heterogen и разное количество ног у корпусов. Только не могу найти, как это сделать. OrCAD 10.x. Жду вашего опыта.

Отлично. Почти собрал этот исходник. Осталось только немного разобраться с CANIDT? . Надеюсь, что скоро заработает. Критической ситуацией с подтверждениями я хотел обозначить следующее: Предположим, надо добиться синхронного начала работы N слейвов. Мастер последовательно настроил их, после этого должен дать инструкцию "старт". Если пользоваться modbus, то вариантов два (с дополнительной линией и без). 1. С дополнительной линией: выставляем на ней сильный ноль - все клиенты стартовали. Так же в неожиданный момент времени любой клиент самостоятельно выставляет ноль на линии => все замирают и мастер начинает последовательно перебирать слейвов, чтобы разобраться, что случилось. 2. Мастер всем синхронирнизовал часы, после чего шлёт первому инструкцию стартовать через deltaTn. Получает подтверждение, шлёт второму deltaT(n-1) и т.д. В итоге, если на каком -то слейве произошёл сбой, то мастер шлёт броадкаст, что надо отложить старт на 1 попытку связи. Проблема в том, что для паранои это сообщение само может быть не получено одним из слейвов и он начнёт работать не в нужное время. До сих пор не смог внятно понять, как реализуется подверждения приёма всеми узлами броадкаста в CAN шине. Жду ответа.

Письмо я направил на [email protected], 17 Фев 2006 16:39:00. Тогда связываемся через форум. Мне надо получить внешний CAN (1шт, к нему очень желательно исходник на С - мне надо понять способ реальной работы с CAN, поскольку я никак не могу пробиться на начальную стадию ("когда кто-то кому-то как-то что-то передал")). Иными словами я обещаю, что исходник "дальше меня" не пойдёт, не будет использоваться как часть или целое в коммерческих проектах, не будет опубликован в любом виде и что единственный способ использования - самообразование ;-) В итоге я хочу купить в Москве 1 шт. USB-CAN-ext-06 с исходником (или частью исходника, отвечающей за CAN). Владимир.

Пока изучаю, ещё не компилировал. После обдумывания ситуации и изучения просторов интернета я понял, что ясного представления о "CAN" в терминах модели OSI у меня нет. Точнее - то я вижу это как UART, то как RS-232, то как modbus over serial (надюсь, что аналогия понятна: mailbox - это уже больше UART, поскольку это обработка; арбитраж мастеров по приоритету - тоже часть функций более высокого уровня; перепосылка... А обработка количества ошибок и отключение от линии- вообще неясно кем выполняется.). По сути, для моих приложений оказалось достаточно ("можно втиснуть") MODBUS/RS-485 @ 0.5MBit. На такой скорости вполне можно обойтись мастером и дополнительной линией синхронизации начала выполнения инструкции, переданной через MODBUS (если стартовый пакет не дойдёт до одного из slave, будет катастрофа). В данном исходнике я вижу нечто подобное уровню физической сети + часть гарантированной доставки сообщения. Более высокий уровень надо мастерить руками и продвинутая версия будет называться DeviceNET, CANOpen e.t.c? При этом я так и не нашёл ни одного исходника "бесплатного" типа. Если посмотреть в форум (недавно начатая ветка про программы/библиотеки IAR C), можно увидеть характерное количество скачиваний файлов типа twi.c, lcd.c, timer.c e.t.c. Можно ли попробовать совместно с Вами написать что-то подобное (или просить Вас выложить более прилизанный каркас?) - т.е. готовое приложение "скомпилировал-залил в две CAN128-на правом жмём кнопочку-левый отвечает помаргиванием". PS Ответа от slavna.ru с предложением о покупке их адаптера USB-CAN не получил пока.

Найденные в продаже устройства: 1. Славна $70 (г.Свердловск). http://www.slavna.ru/stran/devices.htm 2. Rainbow $? (г.Москва) http://www.rtcs.ru/prod_element2.asp?wh_ke...B-CAN&id=401846 3. Много всего http://www.datamicro.ru/can/interfaces/usb-can.shtml 4. Каскод $160 (г.Ленинград). http://www.kaskod.ru/templates/pdf.dop.php...USB-CAN-адаптер 5. Apox $157, $300 исходники http://www.apoxcontrols.com/usbcan.htm (возможно можно заказать через efo.ru http://www.efo.ru/doc/Ftdi/Ftdi.pl?642 - За $140 вероятно более дешёвая версия без опто, $125 на сайте производителя) По производителям софта (наличию хоть чего-нибудь) пока плохо. В качестве платы выбрал www.miklobit.com (MB128-USB-CAN) - Обещали дать в комплект немного рабочего софта.