Greck

угольный...

Забылся? У вас нет трендов... ваш тренд это Пакет1,Пакет2...

Еще микротюниннг: Недоброе дело случилось 10 октября... поцарапал дверь, крыло, бампер задний... теперь вот со страховой терзаюсь, но доп расходов это подкинуло Получение справки в ГАИ за 1н день вместо 2-х недель 150грн Дефектовка у ОД на покраску 180грн Ждем подсчета независ.эксперта и выбираем попутно малярку Так же купил резиноки в блок АБС для устанвоки кнопки СЕТ как у Федора 2шт про запас = 16грн Готовимся к переобувочке на Зиму

Бобма, хочу купить! Как бы их в Украину переслать?

Вауу классная тема... поддержу по свободе картинками)!

MAD_MAX как этот материал? от большого попадания в яму зимой в мороз не сломается чтобы без тормозов не остаться?

задние с завода дисковые?

Каски разные бывают. Хорошо, что машину нашли... ура

ООО коренного Клубня с Днюхой Поздравляемссс)))!!!

у тебя на 704м такое работает?

EvgeniySh а у них значек - открвывает багажник - там другая конструкция...

Serj у нас опция при покупке стоит 200уе там каминливин хоум, датчик света/дождя и подсветка порогов - помоему не дорого)

Ну чтобы было еще больше, я пожелаю самого-самого и еще немного больше С Днюхой!

peremedon к кому обращался?

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

А ты совсем даже и не ВАЗовод...

CAN протоколы высокого уровня CAN протокол получил всемирное признание как очень универсальная, эффективная, надежная и экономически приемлемая платформа для почти любого типа связи данных в передвижных системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами "CAN стандарт" или "CAN протокол" понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. Таким образом, "CAN стандарт" соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже очень простых распределенных систем на базе CAN показывает, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином "CAN протоколы". OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня. Рис. 1 Рис. 2 Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP. Основные возможности протоколов высокого уровня на базе CAN Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня: система назначения идентификатора для сообщения метод обмена данных процесса прямая(peer-to-peer) связь метод установления связей для обмена данных процесса сетевое управление модели и профайлы устройств Идентификаторы сообщений Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это. Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения (рис. 3). Рис. 3 Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений - до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения. DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4): Рис. 4 Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей: явный канал сообщений изменение Master статуса канала (Master Poll Change of State/Cyclic channel) изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel ) Bit Strobe канал Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода - вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения. Oбмен данных процесса Передача данных процесса между устройствами распределенной системы - цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода - вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации процесса. У CANopen передача данных процесса происходит посредством так называемых "Объектов Данных Процесса (PDOs)", у DeviceNet посредством " I/O-сообщений ". В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных ("Transport Classes") . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных. Рис. 5. Device Net Transport ClassesВызов (triggering) сообщений Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и начинается передача сообщения. Передача по состоянию начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения. Установление соответствий (mapping) для программных объектов Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства. Прямые (peer-to-peer) коммуникационные каналы Для конфигурации устройств посредством конфигурационных средств требуются специальные функции у устройств или программы, обеспечивающие многоцелевые каналы связи. Это не критичные по времени каналы связи. Передача данных в них осуществляется посредством протокола с подтверждениями и фрагментацией. Любой из протоколов высокого уровня, которые поддерживают некоторую конфигурацию устройств, должны обеспечивать этот вид связи. DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments). Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response) Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения. Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2. Установление связей для обмена данных процесса Распределение идентификаторов для передаваемых сообщений и , соответственно, получаемых сообщений устанавливает коммуникационные пути в CAN сети. Установление взаимодействия возможно через использование предопределенного множества сообщений с уже размещенными идентификаторами сообщений или через переменное распределение идентификаторов для сообщений. В системе с предопределенным множеством сообщений "функции" и идентификаторы сообщений уже определены. DeviceNet также использует предопределенное множество сообщений для системы со структурой 1:n. Master устройство, предварительно разместив у себя множество связей со Slave устройствами, "знает" ID сообщений для передачи запроса и ID сообщений для получения ответа, который включает Slave MAC-ID в соответствии с предопределенным множеством связей. Также возможно не предопределять идентификаторы сообщений. Сетевое управление Так как в CAN-сети мы имеем дело с распределенными приложениями, должны отслеживаться определенные события(отказы различных частей приложения или отказ устройств). Поэтому главными задачами сетевого управления становятся обнаружение и вывод ошибок в сети и предоставление сервисов, позволяющих контролировать статусы устройств и вести координацию устройств. В зависимости от системных решений сетевое управление может вестись явным или косвенным путем. В DeviceNet каждое соединение контролируется. Поэтому каждая ожидающая сообщение конечная точка имеет "Inactivity/Watchdog" таймер, чтобы контролировать прибытие сообщения согласно предопределенному времени ожидания. Если время истекает, соединение выполняет действие "Timeout". На рис. 7 показана диаграмма изменения состояний у объекта I/O. Рис. 7. Device Net I/O Connection Object State Transition Diagram После получения вызова CREAT ( Explicit сообщение) соединение настраивается при помощи подходящей последовательности вызовов явных сообщений и после этого устанавливается. Перед получением доступа к сети каждое устройство должно совершить проверку на дубликат своего MAC-ID. Определенные алгоритмы выбора гарантируют уникальность MAC-ID. Контроль может осуществляться также посредством Heartbeat сообщения, которое может посылаться устройствам посредством UCMM в форме сообщения. В поле данных этого сообщения передается состояние устройства. Heartbeat сообщение вызывается объектом Idendity. Профайлы устройств Для открытых автоматических систем помимо обеспечения связи от входящих в их состав устройств требуется также обеспечение возможности взаимодействия и взаимозаменяемости. Поэтому протоколы высокого уровня (такие как DeviceNet) описывают функциональные возможности устройств в виде модели устройства ("Device Model"). Помимо описания функциональности устройств модель устройства должна также содержать ряд важных параметров (статус, диагностическую информацию, коммуникационные возможности, конфигурационные параметры и т.д.). На рис. 8 показана модель устройства DeviceNet. Рис. 8. DeviceNet Object Model DeviceNet профайл должен содержать следующую информацию: модель объекта для устройства формат данных I/O для устройства конфигурационные данные и внешние интерфейсы для этих данных В таблице 3 показаны главные функции объектов в DeviceNet. Заключение Протокол CAN применяется в real-time системах для решения различных задач. В настоящий момент развиваются несколько видов CAN протоколов высокого уровня, таких как CAL ,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в основе которых лежит канальный протокол CAN2.0 (Bosch) , и на основе этих протоколов можно решать проблемы, возникающие в real-time системах, которые невозможно разрешить при помощи других известных протоколов, скажем, TCP/IP. источник

Принцип работы механического самоблокирующегося дифференциала Torsen, представляющего собой хитроумное сочетание червячных пар и зубчатых колес, был запатентован в 1958 году — нет, вовсе не гипотетическим шведом Торсеном, а инженером Верном Глезманом. И название Torsen — это не фамилия, а сокращение от двух английских слов torque sensing, то есть "чувствительность к крутящему моменту". Блокировка у этого устройства срабатывает не от разности скоростей вращения валов, как это происходит в вискомуфтах или во многих других дифференциалах повышенного трения, — Torsen реагирует непосредственно на изменение баланса крутящих моментов на валах, причем совершенно без запаздываний. Те межосевые дифференциалы Torsen, которые применяет Audi, в зависимости от условий могут плавно изменять соотношение моментов между валами от 50/50 до 75/25 или, наоборот, 25/75. Сейчас Torsen применяется в качестве межосевого дифференциала на Audi quattro четвертой, шестой и восьмой серий. Но на автомобилях Audi, построенных на общей для концерна VW гольф-платформе — на Audi A3, S3 и на купе и родстерах Audi TT, — передачу крутящего момента на задние колеса осуществляет электронноуправляемая фрикционная муфта, которую по заказу концерна VW разработала и выпускает шведская фирма Haldex. Это многодисковое сцепление, работающее в масле. Оно включается, как только появляется даже незначительная разница в скоростях вращения двух валов — подводящего крутящий момент к муфте и передающего его далее на задний мост. Достаточно отставания выходного вала всего на 45o, чтобы мгновенно сработало нехитрое механическое устройство, оказывая с помощью гидравлики давление на поршни, замыкающие диски сцепления между собой. Запаздывание до полной блокировки сцепления составляет не более 0,2 с — на порядок меньше, чем в вискомуфтах. Но ведь не всегда же нужна полная блокировка! Вот тут-то и вступает в действие электроника. Опираясь на показания многочисленных датчиков (скорости, оборотов двигателя, подачи топлива, скоростей вращения колес от датчиков АБС), "мозг" системы в соответствии с заложенным алгоритмом с помощью перепускных клапанов уменьшает давление на поршни. Поэтому степень блокировки муфты и доля передаваемого на задние колеса крутящего момента зависят от того, как запрограммирован блок управления. А как только пробуксовка колес прекращается, давление в системе исчезает, и Haldex отключается. По словам немцев, одной из причин отказа от механического межосевого дифференциала стали компоновочные трудности, возникшие при попытке вписать Torsen в трансмиссию машин гольф-платформы с поперечным расположением двигателя. Но есть и другая, вероятно, более весомая причина. В соответствии со своей концепцией единой платформы гольф-класса, глава концерна VW Фердинанд Пих с самого начала предусматривал возможность создания унифицированных полноприводных версий для всех базирующихся на ней автомобилей — VW Golf и Bora, Audi A3 и TT, Skoda Octavia, Seat Toledo и Leon. А вариант с электронноуправляемым полным приводом легко позволяет минимальными средствами придавать машинам разных марок концерна индивидуальные черты характера — всего лишь перепрограммируя блок управления системой Haldex. К тому же, при столь внушительном объеме выпуска можно создать весьма совершенное и при этом не столь дорогое в производстве устройство. Вдобавок, по словам ингольштадцев, перед тем, как размещать заказ на разработку и производство системы на шведской компании Haldex, до этого специализировавшейся на производстве гидравлики для тяжелой строительной техники, Фердинанд Пих предусмотрительно выкупил немалый пакет акций фирмы — и теперь получает от растущих продаж полноприводных машин концерна не только моральное, но и материальное удовлетворение. Кстати, в конце 70-х годов Пих работал техническим руководителем Audi, и именно по его инициативе в Ингольштадте начали работу над полноприводной дорожной версией автомобиля Audi 80 Coupe. Так что и появление знаменитого Audi Quattro, в 1980 году ставшего родоначальником всех полноприводных машин из Ингольштадта, и выбор дифференциалов Torsen для межосевого распределения крутящего момента, и нынешний отказ от "механики" в пользу системы Haldex тоже связаны с именем главы концерна. Пих дал, Пих и взял...

sabor Я не знаю как это делать, но лично присутствовал при замене свечей на моем авто... именно так как я тебе нарисовал их ключем с карданчиком и выкручивали... ищи правильный свечной ключик...