Обсуждение:CAN шина

ИНТЕЛ

В ответ на комментарий пользователя ajn1 относительно Intel я нашел этот PPT: http://age-web.age.uiuc.edu/faculty/qzhang/teaching/ABE425/CAN%20Bus.ppt

Заявлено, что Intel разработала первый силикон для шины CAN в 1987 году... также заявлено, что CAN Bus разработана Bosch в 1986 году, вероятно, дата технического документа BMW 1989 год - это когда он был впервые использован/реализован и/или стандарт был окончательно утвержден. Однако в приведенном выше PPT не указан ни один источник, я буду считать это только неподтвержденным доказательством. Я продолжу поиск надежного источника.

NMEA-CAN

Я ничего не знаю о CAN, но я изучал NMEA, который недавно эволюционировал от своих последовательных несущих корней (см. NMEA 0183) до NMEA 2000, который, похоже, использует CAN. Я бы подумал, что это стоит признать.

Продолжайте свою хорошую работу.

Согласен. NMEA 2000 определенно произошел от CAN, поскольку судовые двигатели и электрики, а не более электронные (навигация, связь и т. д.), похоже, управляли им. Пройдя через IEEE 802.4 Token Bus для производства, который в конечном итоге был заменен 802.3, использующим оптоволокно вместо коаксиала для обхода проблем с шумом, я воспринимаю это с долей скепсиса. В морских приложениях я вижу Ethernet для некоторых более общих компьютерных взаимодействий, в то время как NMEA 2000 больше подходит для специализированных микропроцессоров.
Фактором может быть то, что стандарты ISO и NMEA дороги в приобретении. IEEE, похоже, переходит к более открытой модели публикации, которую всегда использовал IETF. Одной из причин провала протоколов OSI была стоимость документов, просто для их оценки.
В какой степени NMEA 2000 должен быть интегрирован в эту статью? Лидерство начинается с автомобилей, но разве применимость не шире? Howard C. Berkowitz 01:02, 2 декабря 2007 (UTC) [ ответить ]

Может ли CRC =

Привет, в статье Купмана он дает canbus crc как 0x62cc

Кто-то изменил это на другой CRC.

могли бы они мне сказать почему пожалуйста? Статья Купмана неверна? (Я в этом как-то сомневаюсь)

-- Робин48gx

Я заметил то же самое. Когда я передаю тот же пакет с STM32, я получаю совсем другой CRC, чем тот, что изображен на схеме. Согласно оборудованию, правильный CRC — 0x7753.

-- Omega — Предыдущий неподписанный комментарий добавлен 73.11.30.201 (обсуждение) 18:36, 17 марта 2017 (UTC) [ ответить ]


Я использовал алгоритм двоичного деления с данными 000000010100000000100000001b (данные с изображения) с полиномом 1100010110011001b (0xC599), как описано в стандарте CAN, и получил 111011101010011b (0x7753), что подтверждает ваше наблюдение.

-- Юни 77.94.130.182 (обсуждение) 15:08, 5 марта 2018 (UTC) [ ответить ]

Синхронный или асинхронный?

Является ли это плезиохронным? Данные отправляются со скоростью с допуском в пределах, скажем, 50 ppm стандартной скорости передачи битов, и поскольку другой конец считывает данные, он ищет кадры и байты. Затем приемник восстанавливает тактовую частоту, которая подразумевалась в полученных данных (из переходов напряжения и линейных кодов?), без отдельных стартовых/стоповых битов или явной схемы синхронизации сигнального элемента.

-- Midnight Hour — Предыдущий неподписанный комментарий добавлен Midnight Hour ( обсуждение • вклад ) 12:30, 22 октября 2014 (UTC) [ ответить ]


Мой первый вопрос о CAN: он асинхронный, синхронный или и то, и другое? Кажется, он асинхронный — в спецификации Bosh говорится: «Шина состоит из одного канала, который переносит биты. Из этих данных можно получить информацию о ресинхронизации». Я новичок в последовательных протоколах и в Википедии... просто хочу убедиться, что «асинхронный» — это правильная классификация CAN... пожалуйста, дайте мне знать. Если так, я разберусь, как добавить это в статью о CAN.

Это немного того и другого. Все узлы синхронизируют свои часы с последним сообщением, которое прошло по шине.

-- Робин48gx

--Кевин Шостек

Он синхронный и широковещательный (без подтверждения, сообщение полностью отправляется после его отправки). Передний фронт бита синхронизации начинает автоматическую повторную синхронизацию. Биты после этого отсчитываются по временной последовательности, а не по отдельному опорному сигналу.

Подробности здесь [1]

-- Джулиан Моррисон 13:33, 7 ноября 2005 (UTC) [ ответить ]

В спецификации CAN B2.0 говорится: «Информация о тактировании может быть получена из переходов от одного значения бита к другому. Свойство, что только фиксированное максимальное количество последовательных битов имеет одинаковое значение, обеспечивает возможность повторной синхронизации блока шины с потоком битов во время кадра. Максимальная длина между двумя переходами, которая может быть использована для повторной синхронизации, составляет 29 битовых времен».

Я не знаю, что означают «29 битовых времен» и «два перехода», кто может меня научить?

---

Этот раздел не обновлялся годами, но он настолько полон неверной информации и вопросов без ответов, что я просто не могу оставить его как есть.

CAN не включает тактовую частоту в передачу данных. Все узлы в сети CAN должны работать с одинаковой скоростью передачи данных, а ошибка между внутренними тактовыми частотами каждого узла должна быть в пределах допуска, чтобы узлы в сети могли взаимодействовать. Это то же самое, что и последовательный порт RS-232 ПК, который считается асинхронным. Многие инженеры (ну, по крайней мере, этот инженер) считают CAN асинхронной передачей данных. Freescale называет это асинхронным в этой заметке по приложению. С другой стороны, спецификация CAN2.0 и ISO11898-1 обсуждают битовую синхронизацию, что, вероятно, заставляет многих, включая CiA в ссылке Кевина выше, называть ее синхронной. Ключевое различие между CAN и тем, что я называю синхронной, заключается в том, что приемопередатчики CAN не синхронизируют свой прием данных с помощью фронта тактовой частоты, а выводят тактовую частоту с помощью фронта передачи данных. Синхронизация — это синхронизация на уровне битов между узлами, где каждый узел отслеживает фронты данных и может корректировать точку внутри бита, которую он выбирает для выборки данных.

Синхронизация узлов важна по двум причинам:

Во-первых, для работы схемы арбитража CAN все узлы должны быть синхронизированы, чтобы они отправляли или получали биты одновременно [2]. Все узлы в арбитраже должны одновременно выбирать как свои собственные биты идентификаторов, так и биты идентификаторов других узлов.

Во-вторых, ACK определенно есть (извините, Кевин, но вы ошибаетесь, см. спецификацию CAN 2.0 от Bosch по ссылке в начале этого раздела). Ближе к концу кадра данных CAN находится поле ACK. Передающий узел отправляет два рецессивных бита (двоичный один - пассивный) в слот ACK и ожидает увидеть доминантный бит (двоичный ноль - активный) в этом слоте. Каждый узел, который получает действительный кадр CAN, должен отправить доминантный бит (активно управлять двоичным нулем на проводах CAN) в слот ACK. Активный ноль переопределяет пассивный, и передающий узел увидит ACK. Поскольку передающий узел видит ACK, он знает, что кадр был получен по крайней мере одним узлом. Если передающий узел не видит ACK, он немедленно повторно отправляет кадр. Если в сети работает только один узел, первый отправленный им кадр не будет ACK, и он немедленно повторно отправит его, снова и снова. Это переполнит сеть трафиком CAN. Такая синхронизация гарантирует, что приемник CAN (который передает ACK) генерирует ACK в том месте, где передатчик его видит, и не ретранслирует кадр.

Поскольку данные CAN являются NRZ, есть только переходные края, по которым приемник может синхронизироваться. То есть, когда значение текущего передаваемого бита отличается от значения предыдущего бита (от нуля до единицы или от одного до нуля). Жесткая синхронизация происходит на начальном бите, а повторная синхронизация происходит на каждом рецессивном переходе к доминантному после этого. Для повторной синхронизации приемника передаваемые биты должны изменить значение. Поскольку передаваемые данные могут быть полностью нулями или полностью единицами, CAN 2.0 и ISO11898-1 требуют вставки битов. Когда передатчик обнаруживает пять последовательных битов с одинаковым значением (включая вставленный бит), он «вставляет» дополнительный бит в поток данных. Затем приемник должен «извлечь» бит из входящего потока данных. В спецификации CAN 2.0B компании Bosch действительно указано, что «Максимальная длина между двумя переходами, которая может использоваться для повторной синхронизации, составляет 29 битовых времен». Я не знаю, почему, поскольку та же спецификация требует вставки битов на уровне пяти бит, а это означает, что между двумя рецессивными и доминантными переходами будет максимум десять бит.

Для меня это означает, что данные CAN передаются в асинхронном формате, но все узлы в сети CAN «синхронизированы» для одновременной выборки передаваемых данных.

Отвечая на вопросы Джулиана, переход — это когда следующий переданный бит меняет значение предыдущего бита. Два перехода означают, что значение бита меняется, а затем возвращается к предыдущему. «Время бита» — это промежуток времени для передачи одного бита, и является обратной величиной скорости передачи битов. Скорость передачи битов 125k составляет 8uS времени на бит. 29 битовых времен при 125kbit составляет 29 раз по 8uS или 232uS.

EE JRW ( обсуждение ) 02:13, 12 июля 2014 г. (UTC) [ ответ ]

Я обнаружил, что у меня было несколько недопониманий по этому предмету, и отредактировал свои предыдущие комментарии, чтобы исправить наиболее вопиющие ошибки. Я надеюсь использовать свое новое (недостающее?) понимание, чтобы вскоре расширить раздел Bit Timing EE JRW ( talk ) 16:03, 1 января 2015 (UTC) [ ответить ]

Возможна ли выборочная передача данных с помощью CAN?

Привет

В моем приложении 4 ЭБУ подключены к шине CAN. Могу ли я выборочно отправлять сообщения одному ЭБУ и не отправлять их другим ЭБУ, используя CAN? Как использовать маску или фильтры для этого?

Спасибо, Перл

Любое сообщение в CAN всегда передается в широковещательном режиме. Поскольку передатчик не имеет никаких знаний о приемниках. Любой приемник должен сам решить, заинтересован ли он в определенном сообщении. Фильтрация может быть выполнена программно или аппаратно. Если фильтрация выполняется аппаратно, то руководство по фильтрации — это документация соответствующего контроллера CAN. -- MisterTS 19:27, 9 марта 2006 (UTC) [ ответить ]
Чтобы продолжить. CAN — это только широковещательная передача. У него нет адресации, как у Ethernet или Интернет-протокола . Вместо этого у него есть идентификаторы сообщений, которые говорят «вот что в этом пакете», и каждый узел должен решить, обрабатывать его или отбрасывать.
Я предполагаю, что у вас есть в основном четыре одинаковых ЭБУ, с которыми вы хотите выборочно общаться. Если у вас нет программного управления ЭБУ, чтобы установить какой-то вид адресации в идентификаторе (например, резервирование первых двух бит как адреса ЭБУ), то вы не сможете сделать это без изоляции каждого ЭБУ на его собственной шине и установки "переключателя", соединяющего все четыре шины, который понимает какой-то метод адресации. Cburnett 01:02, 10 марта 2006 (UTC) [ ответить ]
SAE J1939 (используется для тяжелых грузовиков и автобусов), который использует 29-битные адреса, имеет метод выборочной отправки сообщений на один ЭБУ. используя 8-битные адреса ЭБУ. Для этого нет места в 11-битных адресах, обычно используемых для легковых автомобилей. При желании это должно быть помещено в данные полезной нагрузки.-- BIL ( обсуждение ) 21:56, 1 января 2015 (UTC) [ ответить ]

Программируемый интерфейс связи DaimlerChrysler (PCI) и CAN

Совместимы ли эти две шины друг с другом? Я видел, как блок инструментов PCI получал сообщения на CAN PCM. Я не уверен, был ли блок инструментов совместим и с PCI, и с CAN, или PCI и CAN в основном совместимы.

какие компоненты (аппаратное и программное обеспечение)

Мой вопрос: какие компоненты, как аппаратные, так и программные, потребуются для создания CAN BUS между несколькими микроконтроллерами или FPGA? Где я могу найти такую ​​информацию?

Спасибо,

Джером

Вам нужен контроллер CAN (например, MCP2510 от Microchip) и трансивер CAN (например, PCA82C250 от Philips). Контроллер дает вам логический интерфейс, а трансивер дает вам физический интерфейс. Плюс программное обеспечение для взаимодействия с контроллером. Вы можете получить микроконтроллеры со встроенными контроллерами, поэтому вам нужен только трансивер. Cburnett 22:30, 31 декабря 2006 (UTC) [ ответить ]


Диаграмма битовой синхронизации

Я добавил раздел «Битовый тайминг» к диаграмме, но для этого нужно добавить гораздо больше текста. Rocketmagnet 11:11, 9 января 2007 (UTC) [ ответить ]

Представитель компании, которая поддерживает веб-сайт с обучающими материалами по CAN, попросил меня добавить их в раздел внешних ссылок. Он или она не сделали этого сами из-за WP:COI . Я сказал, что это следует обсудить, а не предоставлять мне единоличное решение, поэтому я размещаю это здесь.

Вопрос: Не могли бы вы оценить следующую ссылку, которая ведет к очень подробному руководству по CAN? http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-bus/communication/broadcast.php?navanchor=3010076
Поскольку я аффилирован с компанией Softing, я не должен добавлять эту ссылку. Вместо этого я хотел бы попросить вас как нейтрального редактора оценить эту ссылку и добавить ее в раздел внешних ссылок статьи Controller Area Network, если вы считаете, что ссылка предоставляет ценную информацию.

Что все думают? -- Selket 18:32, 2 февраля 2007 (UTC) [ ответить ]

Selket, я нахожу контент по ссылке интересным и ценным - я не вижу проблемы в том, что он исходит от компании. Это хорошая практика для способных компаний - вносить контент и делать его доступным для всех. Это хороший пример.

 Соня Триер, s.trier@web.de

Я нашел на сайте некоторую дезинформацию: «Примечание: пассивные реализации спецификации CAN 2.0 B не могут хранить или передавать расширенные кадры данных; активные реализации спецификации CAN 2.0 B могут хранить и передавать как стандартные кадры данных, так и расширенные кадры данных»

Вопрос: Не могли бы вы более конкретно рассказать о дезинформации?

Рекомендация: укажите эту ссылку как второй источник информации о CAN:
Если все в порядке, давайте укажем эту внешнюю ссылку как второй источник для образовательной страницы CAN. 68.236.126.218 17:59, 4 апреля 2007 (UTC) [ ответить ]


Различные инструменты доступны для разработки CAN-систем с использованием этих протоколов высокого уровня. Например:
CANopen Configurator[3]
X-Analyser for CAN[4]
CANoe[5]
Teknewell Engineering[6]
CANalyzer[7]
CANsniff
CANgate

Должны ли мы также удалить ссылку[8] от 24.91.109.193 на TekNewell, которая, похоже, представляет собой не более чем коммерческий программный пакет для взаимодействия с CAN? -- Symmetry 18:47, 4 октября 2007 (UTC) [ ответить ]
Отличное программное обеспечение обеспечивает производительность и эффективность на заводах. Нам следует сохранить связь.

Загадочная таблица

Может ли кто-нибудь объяснить, а затем исправить таблицу в статье (скопированную ниже для справки). Я понимаю CAN, я понимаю доминантный и рецессивный, я понимаю функцию AND. Я не понимаю таблицу - что такое столбцы, что такое строки, почему одна ячейка пуста, почему некоторые записи выделены жирным шрифтом? -- SGBailey 19:32, 31 июля 2007 (UTC) [ ответить ]

Таблицы истинности для доминантного/рецессивного и логического И
Состояние шины с двумя передающими узлами
 доминирующийрецессивный
доминирующийдоминирующийдоминирующий
рецессивныйдоминирующийрецессивный
Логическое И
 01
000
101

OK, я догадался. Левый столбец и верхняя строка — это входные данные, а нижний правый 2*2 — это результат. Я изменю таблицу, чтобы я мог ее понять, и если вам другим она не понравится, верните ее обратно. -- SGBailey 19:36, 31 июля 2007 (UTC) [ ответить ]

Таблица неинтуитивна; Доминантный — 0, а рецессивный — 1. Почему? — Предыдущий комментарий без знака добавлен 147.177.201.37 (обсуждение) 12:25, 1 августа 2011 (UTC) [ ответить ]

---

Эта таблица настолько запутанная (и бессмысленная), что я ее удаляю. Если вам интересно, что было, вот она.

Таблицы истинности для доминантного/рецессивного, логического или и логического и (для сравнения)
Состояние шины с двумя передающими узлами
ДоминантныйРецессивный
ДоминантныйДоминантныйДоминантный
РецессивныйДоминантныйРецессивный
Логический или
01
001
111
Логично и
01
000
101

Вместо этого я добавляю новую таблицу с битами идентификатора и разрешением конфликтов, описанными в тексте. Это моя первая попытка вики-таблицы, и я не очень доволен ею. Я был бы рад, если бы кто-то, кто разбирается в таблицах, улучшил ее. В частности, ID10, ID9 и т. д. должны иметь метку над ними, говорящую о бите идентификатора узла, затем каждый столбец под битом идентификатора узла должен просто содержать номер бита. EE JRW ( talk ) 00:59, 22 ноября 2014 (UTC) [ reply ]

Ничего, я в конце концов разобрался. Теперь я доволен новым столом EE JRW ( обсуждение ) 17:34, 31 декабря 2014 (UTC) [ ответить ]

ЭБУ ???

Хотя я могу принять, что ECU может означать электронный блок управления. DaimlerChrysler (как и было) всегда использовал ECU для обозначения блока управления двигателем! TinyMark 20:58, 6 ноября 2007 (UTC) [ ответить ]

-Я всегда понимаю, что ECU означает блок управления двигателем в контексте автомобилей. BMW называет это "DME" (цифровая электроника двигателя). —Предыдущий неподписанный комментарий добавлен 64.238.175.105 (обсуждение) 12:25, 24 ноября 2007 (UTC) [ ответить ]

Есть ли у кого-нибудь ссылка на это? Я добавил текст на страницу, исходя из того, что то, что я добавил, должно быть лучше, чем просто перегружать аббревиатурой без объяснений, но, вероятно, должна быть ссылка. JacobBramley ( talk ) 06:19, 10 июля 2008 (UTC) [ ответить ]

- ISO11898-2 перечисляет это в Таблице сокращений (Раздел 4). Пользователь:d_rock_naut 25 июля 2008 г.

«С другой стороны, любое официальное использование CAN [...]»

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

Действительно, лицензия протокола CAN на сайте Bosch не распространяется на использование существующих контроллеров CAN, а предназначена для разработчиков ASIC или программистов FPGA. Я не вижу ограничений на использование CAN в микроконтроллере LPC2129 от NXP, например, но я предполагаю, что NXP должна была заплатить лицензионный сбор.

Я подозреваю, что утверждение на странице частично неверно. У меня нет цитаты, подтверждающей это, но также нет цитаты, подтверждающей полный объем существующего текста.

Может ли кто-нибудь, кто знает больше о CAN, рассказать подробнее?

JacobBramley ( обсуждение ) 06:35, 10 июля 2008 (UTC) [ ответ ]

Я также понимаю, что разработчики FPGA/ASIC платят лицензионный сбор Bosch. Пользователи контроллеров CAN не платят. Brolin ( talk ) 13:25, 22 июля 2008 (UTC) [ ответить ]

Как и в случае с любым патентом, которым владеет кто-либо, во всей цепочке производитель/пользователь платит за лицензию только один, в зависимости от того, кто нарушает патент. Bosch решила, что любой, кто распространяет CAN в какой-либо реализации, должен платить за лицензию. Это означает, что любой производитель микросхем, такой как Infineon, Freescale, Renesas, как вы его называете, должен платить. Это включает также любую реализацию в ASIC или FPGA. Потому что, например, Altera не распространяет реализацию CAN, но я делаю это, если я реализую CAN в одном из чипов Altera. Так что мне пришлось бы платить. Но любой, кто использует чипы, включая тот, который я распространяю на основе Altera, не должен ничего платить.
Как обычно, никто не реализует CAN, а использует его как любое другое последовательное соединение, как RS232 или Ethernet, это бесплатно. Почти никто не реализует RS232 или Ethernet самостоятельно, а использует доступные чипы контроллера. То же самое относится и к CAN. -- MisterTS ( talk ) 14:19, 20 августа 2008 (UTC) [ ответить ]

межкадровый интервал

Из статьи: «Интервал между кадрами обычно составляет 96 бит. Он дает время машинам в сети Ethernet прослушивать и отправлять данные»

Это, очевидно, неверно. Правильный межкадровый интервал составляет около 6 бит, и Ethernet тут ни при чем. Brolin ( talk ) 13:25, 22 июля 2008 (UTC) [ ответить ]


Одни банальности!

В этой статье есть контент, который выдаётся за знания, но на самом деле представляет собой просто банальности:

«Этап интеграционного тестирования требует, чтобы «живые» ЭБУ были впервые соединены между собой, и конечной целью этого этапа является устранение всех причин поведения системы, которые могут негативно повлиять на надежность выпускаемой продукции».

«Ограничения по времени требуют эффективного использования процессов тестирования, доступных ресурсов и инструментов для обеспечения высочайшего уровня качества продукта по завершении этапа интеграционного тестирования. Команды тестирования должны обладать средствами для выявления и изоляции неисправностей, а также опытом, необходимым для быстрой оценки возможных первопричин. Время, необходимое для фактического отслеживания и устранения режима первопричины отказа, часто может быть чрезвычайно сложным и неэффективным по времени в широко распределенных процессах».

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


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

Признаками банальностей, противопоставляющих реальным знаниям, являются такие фразы, как «устранить все причины поведения системы, которые могут негативно повлиять на надежность выпускаемой продукции» (это общая цель качества, не относящаяся только к CAN), «эффективное использование процессов тестирования» (скажите, где НЕТ необходимости в эффективном использовании процессов тестирования? Что это за процессы и какие из них применимы к интеграции систем CAN по сравнению с другими сценариями интеграции систем?), «Группы тестирования должны обладать средствами для выявления и локализации неисправностей» (пожалуйста, просветите меня; как ЭТО должно быть достигнуто в контексте интеграции систем CAN? Вы действительно знаете как? Пожалуйста, скажите!)

Последняя цитата — настоящая жемчужина: это утопический инструмент, который должен выполнять работу инженера-испытателя, чтобы ему/ей не приходилось этого делать. Существует ли он на самом деле или это просто плод чьего-то воображения? За неимением конкретных примеров такого инструмента я бы выбрал второе, а не первое: такого инструмента не существует.

Эти банальности, на самом деле, не ограничиваются интеграцией систем CAN; они свойственны ЛЮБОЙ системной интеграции. Они не добавляют ценности этой статье (или любой другой). Я предлагаю вычеркнуть их и просто описать процесс системной интеграции, если у автора нет реальных знаний о том, как добиться такой интеграции в контексте CAN. — Предыдущий неподписанный комментарий добавлен Lamp90 ( talk • contribs ) 04:04, 1 августа 2008 (UTC) [ ответить ]

Я помогаю уменьшить банальности и улучшить плотность знаний в других разделах этой статьи. Если я наступлю на мозоли, дайте мне знать. Hobson Lane ( talk ) 14:52, 18 декабря 2011 (UTC) [ ответить ]

CAN 2.x

Может ли кто-нибудь рассказать, чем отличается CAN 2.x от предыдущих стандартов (CAN)?

Насколько мне известно, в CAN 2.0 введены 29-битные идентификаторы.

Юлиан-Нику Шербанойу 15:03, 20 декабря 2010 г. (UTC) — Предыдущий неподписанный комментарий добавлен Юлианом.сербанойу ( обсуждение • вклад )

Запрошенный ход 1

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

Результатом запроса на перемещение стала страница, перемещенная .  Скоморох , варвар  10:14, 20 октября 2009 (UTC) [ ответить ]


Контроллер–локальная сеть → Контроллерная локальная сеть — n-тире между контроллером и областью не имеет грамматического смысла. Дефис был бы грамматически допустимым вариантом, но в спецификации ISO для протокола используется только пробел. -- Эд Брей ( обсуждение ) 20:44, 12 октября 2009 (UTC) [ ответить ]

Поддержка — короткое тире используется для обозначения диапазона между числами и не должно использоваться для переноса или соединения слов/названий. (В этом ответе я использую короткое тире после слова «поддержка» для начала абзаца и перед подписью.) Короткое тире на 100% неправильно использовано в названии статьи. – Keraunoscopia ( обсуждение ) 21:09, 12 октября 2009 (UTC) [ ответить ]
Вышеуказанное обсуждение сохраняется как архив запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на этой странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.

Компании, предоставляющие продукцию и информацию о CanBus для транспортных средств

Информация о системе сигнализации и слежения CANBus (контроллерная локальная сеть) доступна на [canbus.pfkelectronics.com]название ссылки

Протокол передачи данных (цифровые коды) для управления и мониторинга функций большинства современных автомобилей с шиной CAN идентифицируется с помощью диагностических инструментов, доступных только проверенным дилерам.

Цифровые коды CANbus передаются по двухпроводной сети CANbus, называемой BUS, отсюда и слово CANBus или CAN BUS. Существуют и другие интерфейсы, используемые для получения кодов CAN, поскольку большинство производителей не будут легко делиться этой информацией, если вам требуется продукт, который соединит ваше устройство с системой CANbus на транспортном средстве, вам следует сначала взглянуть на то, что уже доступно — Предыдущий неподписанный комментарий добавлен Gregmelson (обсуждение • вклад ) 10:56, 4 марта 2010 (UTC) [ ответить ]

Патентное лицензирование?

Хотя первоначальные патенты на реализации 1980-х годов, очевидно, истекли, какая часть новых патентов все еще заставляет людей лицензировать их? Кажется, вы просто не могли использовать новые функции? 71.196.246.113 ( talk ) 05:00, 19 июня 2011 (UTC) [ ответить ]

AFAICT, это различие скоро станет неактуальным: патент, основанный на документах, опубликованных в 1991 году, также должен быть близок к истечению срока действия, если уже не истек. 212.159.69.4 ( обсуждение ) 19:06, 18 декабря 2011 (UTC) [ ответ ]

Запрошенный ход 2

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

Результатом запроса на перемещение было: Нет консенсуса по перемещению на новое название Майк Клайн ( обсуждение ) 22:59, 2 января 2012 (UTC) [ ответить ]


Controller area network → Controller Area Network – Этот запрос следует примеру других статей Википедии о технических стандартах и ​​спецификациях сетевых шин. Универсальная последовательная шина – самое близкое, что я могу придумать. Заглавный регистр подходит для темы этой статьи, поскольку это имя собственное, название конкретной стандартизированной реализации сети для контроллеров. Опрос Google подтвердил это.. повторно перечислено -- Майк Клайн ( обс. ) 01:37, 26 декабря 2011 (UTC) Хобсон Лейн ( обс .) 14:41, 18 декабря 2011 (UTC) [ ответить ]

  • Согласен , сделай это.-- Asher196 ( обсуждение ) 15:01, 18 декабря 2011 (UTC) [ ответить ]
  • Oppose . Орган по стандартизации не пишет название с заглавной буквы в этом отрывке, а в этом — во множественном числе . Множественное число, в частности, предполагает, что «controller area network» можно считать нарицательным. Я не эксперт по этой теме, и эта статья плохо цитируется, поэтому я не могу полагаться на использование в источниках статьи, чтобы определить, используется ли оно как нарицательное. Так же, как и стиль ISO, стиль Википедии может отличаться от общепринятого использования. Например, Storage area network (нарицательное существительное, по моему мнению) пишется в Википедии без заглавной буквы, несмотря на то, что многие американо-английские источники используют заглавные буквы. Я никогда не видел, чтобы уважаемый англоязычный источник использовал множественное число Universal Serial Bus , и считаю его именем собственным . Блоги, которые использовали «Universal Serial Buses», ссылались на несколько версий стандарта USB. Я также не видел, чтобы уважаемый источник рассматривал «Universal Serial Bus» как общую вещь (шину), а скорее как описание разъема или в избыточной форме «шина USB». Также в Википедии Internet protocol suite недавно был переведен в строчную форму (хотя я не думаю, что я бы поддержал этот шаг). «Open source» редко пишется через дефис в англоязычных источниках, но в Википедии он пишется через дефис как составное прилагательное. Лингвисты (!) не пишут через дефис разрешение неоднозначности смысла слова . Применение руководств по стилю — дело непростое. Мне было бы интересно вернуться к вопросу, когда эта статья достаточно хорошо цитируется, чтобы дать хорошую выборку надежных, высококачественных источников. –  Pnm ( обсуждение ) 05:58, 19 декабря 2011 (UTC) [ ответ ]
  • Поддержка Использование заглавных букв в стандартах ISO зависит от того, кто пишет. Например, этот другой стандарт использует заглавные буквы в термине Local area network [9], который в Wikipedia пишется строчными буквами. В любом случае, это собственное имя конкретного протокола, регулируемого конкретной организацией. -- Энрик Навал ( обсуждение ) 23:24, 29 декабря 2011 (UTC) [ ответить ]
  • Oppose . Если это конкретный стандарт, то можно уважать заглавные буквы в стандарте, которые являются строчными. Нередко можно встретить строчные буквы в книгах, и это очень распространено в научных статьях. Dicklyon ( talk ) 18:15, 1 января 2012 (UTC) [ ответить ]
  • Самая сильная поддержка Каждый из надежных источников, упомянутых в нашей статье «Внешние ссылки», использует все заглавные буквы. Этот список включает этот научный трактат по теме, а также спецификацию Bosch для стандарта, который они создали. Это не входит в компетенцию простых википедистов, чтобы гадать, как реальный мир применяет или неправильно применяет английский язык, или пытаться подавать пример в надежде Показать миру новый и лучший мировой порядок для применения имен собственных на английском языке ®™©. Самые надежные RS последовательно пишут его как Controller Area Network (CAN) . Wikipedia должна следовать за потоком RS. Грег Л ( обс .) 20:15, 1 января 2012 (UTC) [ ответить ]
    Грег, ты ошибаешься насчет этих источников. Я согласен, что важно не отходить слишком далеко от источников; но посмотрите внимательнее на эти внешние ссылки:
    1; да, создатель термина, Bosch, хочет, чтобы он был написан с заглавной буквы; ничего удивительного. Но он стал официальным стандартом, о чем и идет речь в статье, а официальный стандарт не пишет его с заглавной буквы.
    2; если вы скачаете PDF и посмотрите, то увидите там "Сети контроллеров" и заголовок "Сеть контроллеров". Определенно, здесь нет особой поддержки для интерпретации имени протокола как имени собственного.
    3 оно присутствует только в названии и в определении аббревиатуры; здесь нет существенной поддержки для толкования имени собственного.
    4 содержит его только в сокращенном определении.
    5 содержит его только в аббревиатуре.
    6 использует его в тексте только как «Controller Area Networks»; это не может быть названием протокола и предполагает общее использование.
    Вот почему я предложил вместо этого следовать стандарту ISO; это, по-видимому, «самый надежный» для статьи о стандарте. Другие надежные источники, которые используют строчные буквы, тем самым предполагая, что этот термин не принимается в качестве имени собственного, включают эту книгу, эту книгу и эту книгу. На самом деле сложнее найти книги, которые используют его с заглавной буквы для обычного использования в предложении; почти все заглавные буквы используются в названиях статей, заголовках и определениях аббревиатур. Аналогично нет недостатка в научных статьях, таких как эта, эта и другие, среди тех, где используются строчные буквы, и бесплатных PDF-файлов в Интернете. Настоящее имя собственное — CAN; нет никаких доказательств того, что я могу найти, что то, что расшифровывается как CAN, также является именем собственным. В надежных источниках есть множество прецедентов, чтобы относиться к «сети контроллеров» как к «локальной сети» и «глобальной сети»: вещам, из которых делают аббревиатуры, но не именам собственным. Dicklyon ( обсуждение ) 21:45, 1 января 2012 (UTC) [ ответить ]
  • Вопрос Это общий класс сетей (как локальная вычислительная сеть ) или определенный тип шины (как универсальная последовательная шина )? Лидер немного двусмыслен по этому поводу. — Ruud 23:11, 1 января 2012 (UTC) [ ответить ]
    • Определенный тип. Это определенный стандарт для определенной шины микроконтроллера. Мой лучший друг — суперэксперт в этом деле, и он занимается этим с самого начала эпохи цифровых контроллеров (еще до 8051). Термин относится к *определенной* шине и всегда пишется заглавными буквами, потому что термин относится к определенной шине, изобретенной Bosch, — как и изобретение Intel универсальной последовательной шины (USB) , которая является определенной. Если вы посещаете занятия или семинар по CAN, как здесь, в Embedded Systems Academy, это полнодневный практический курс по Controller Area Network (также известной как шина CAN или CANbus). Теперь…

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

      Я отмечаю, что в этой статье изначально использовалось правильное написание, а RM, в котором участвовали всего два человека , изменил его. Неправильно; статья была правильной с момента ее создания в 2003 году (редакторами, которые понимают этот материал) до 2009 года, когда эти два редактора в RM похлопали друг друга по спине и сказали: «Хорошее шоу — во всех смыслах».

      Сейчас у нас есть редакторы, которые активно работают над тем, как английский язык должен правильно делать то или иное, но у которых практически нет опыта в этой конкретной дисциплине. И, как всегда, у каждого , у кого есть мнение, есть голос в Википедии. Это замечание может оскорбить, но у Википедии есть политика, которая называется Компетентность обязательна . Короче говоря, этот РМ правильно урегулирован не подсчетом носов, а силой и весомостью аргументов. То, что кто-то желает , чтобы что-то было по-другому в мире, не делает обязательным, чтобы Википедия позволяла эксплуатировать себя как средство для изменения реальности на то, что некоторые считают лучшим. Грег Л ( обсуждение ) 23:35, 1 января 2012 (UTC) [ ответить ]

      Я был бы первым, кто согласился бы на заглавные буквы, если бы все источники это делали. Как я уже указывал выше, определяющий стандарт этого не делает, и я привел несколько книг и статей, которые этого не делают, из тех, что видны в сети; я могу дать еще ссылки. И для протокола, я не некомпетентен; я работал над системами, которые отправляют фирменные данные по автомобилям по шине CAN; но мы никогда не называли это Controller Area Network, что является источником названия CAN, но по сути является общим само по себе. Даже ссылка на курс, которую дает Грег, использует этот термин только один раз, при представлении аббревиатуры. Несколько источников на самом деле представляют аббревиатуру со строчной буквы controller area network, предполагая, что они специально хотели избежать впечатления, что Controller Area Network — это название. Что касается первого RM выше, это было исправление странной ошибки пунктуации; изменение на строчные было сделано еще в 2008 году. Dicklyon ( talk ) 23:57, 1 января 2012 (UTC) [ ответить ]
      • Спецификация Bosch для CAN 2.0 здесь. Обычно в документе пишут «CAN». Но «Controller Area Network» написано три раза. Это Bosch сейчас, и все три раза это написано заглавными буквами. Это в точности как Universal Serial Bus от Intel . Несмотря на то, что даже RS, такие как Microsoft, здесь иногда ошибаются и пишут это как universal serial bus , это не означает, что мы должны цепляться за это как за оправдание, потому что это на самом деле «Universal Serial Bus», и даже Microsoft может иногда сделать это правильно. Грег Л ( обс .) 00:09, 2 января 2012 (UTC) [ ответить ]
  • строчные буквы Я в отрасли. Я перестал писать с заглавной буквы, когда понял, что копирую название из официальных спецификаций и должен сам добавлять заглавные буквы. Причина, по которой «любой в отрасли» пишет с заглавной буквы, заключается только в том, что никто никогда не называет это «контроллерной локальной сетью», это всегда называется CANbus (и варианты) с аббревиатурой. Энди Дингли ( обсуждение ) 00:11, 2 января 2012 (UTC) [ ответить ]
    • Это не так, как вы пишете. Embedded Systems Academy пишет (и это полная и достоверная правда): Практический курс на целый день по Controller Area Network (также известный как CAN bus или CANbus). А спецификация Bosch для CAN 2.0 здесь. Грег Л ( обсуждение ) 00:20, 2 января 2012 (UTC) [ ответить ]
      • Первая — это учебный дом, который эндемически использует заглавные буквы, потому что это заставляет вещи звучать более важными. Вторая — немецкая, а немецкие источники также имеют присущую тенденцию писать заглавные буквы в существительных, особенно сложных. Вы заметите, что у Bosch на каждую полную версию имени приходится дюжина, где оно CAN. Можно ли представить, что IBM когда-либо сделает то же самое? Энди Дингли ( обсуждение ) 00:40, 2 января 2012 (UTC) [ ответить ]
      Извините, если мое утверждение "использует термин только один раз, при представлении аббревиатуры" было немного вводящим в заблуждение относительно формы; но я буду придерживаться его ради принципа, почему они пишутся с заглавной буквы. Ах, но вы же не со мной говорили; извините. Dicklyon ( talk ) 00:25, 2 января 2012 (UTC) [ ответить ]
    • Разве не следует нам перенести это в CANbus в таком случае? Это позволило бы избежать как двусмысленности, связанной с тем, что это определенный тип шины/сети, так и, как обычно, пустых дебатов по поводу правописания. — Ruud 00:22, 2 января 2012 (UTC) [ ответить ]
      Я думаю, это была бы хорошая идея; или CAN шина , в зависимости от того, что более распространено или более стандартно. N-граммы предполагают CAN шину . – Dicklyon ( обсуждение ) 00:25, 2 января 2012 (UTC) [ ответить ]
      • Меня это вполне устраивает. Что бы мы ни делали, мы должны убедиться, что уделяем время тому, чтобы посмотреть, как на самом деле и наиболее авторитетно с этим справляются инсайдеры в этой отрасли . Если есть несколько способов, не помешает быть честным и сказать Controller Area Network , также известная как CAN bus или CANbus . Нам не нужно иметь идеальную согласованность и кристально чистую, нулевую неоднозначность даже в рамках этой дисциплины, если таковой на самом деле не существует. Я просто не терплю википедистов, которые ищут согласованность между проектами и пытаются протолкнуть Хорошие Идеи©™®, например, как в нашей статье « Гравиметрия » следует сказать, что градиент силы тяжести (изменение с высотой) над поверхностью Земли составляет около3,1 × 10−6  с –2, потому что обратные секунды в квадрате имеют чистоту СИ и достигают согласованности по всему проекту ( а мы издательство и можем иметь собственное руководство по стилю, бла-бла-бла). Это нарушение Технического Письма 101 для меня удивительно, потому что вся дисциплина гравиметрии — от НАСА и их спутниковых измерений до ботинок на земле с пружинными гравиметрами — всегда пишет так Градиент силы тяжести (изменение с высотой) над поверхностью Земли составляет около 3,1 мкГал на сантиметр. Мы всегда оказываем нашим читателям услугу, используя разговорный язык, действительно используемый в этой области, без предубеждения против истинных фактов. Грег Л ( обсуждение ) 00:40, 2 января 2012 (UTC) [ ответить ]
        Правда, в таких случаях нужно включать альтернативные формы в скобках. Не будучи специалистом по гравиметрии, я не знал, что такое Гал (единица) , но чистые единицы СИ также, вероятно, смутили бы меня. Не то чтобы я ратовал за (фут/сек/сек)/фут, но некоторые из нас выросли и на этом. Эй, это тоже будет 3.1E-06. Dicklyon ( обсуждение ) 01:13, 2 января 2012 (UTC) [ ответить ]
        Oppose . Но я не против перехода на CANbus или CAN bus ; в этом случае, если/когда он будет расширен в тексте статьи, он должен быть написан строчными буквами. Tony (обсуждение) 01:31, 2 января 2012 (UTC) [ ответить ]
Вышеуказанное обсуждение сохраняется как архив запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на этой странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.

Запрошенный ход 3

Почему это было закрыто во время столь активного обсуждения? -- Asher196 ( обсуждение ) 23:27, 2 января 2012 (UTC) [ ответить ]
Хотите, чтобы я отменил закрытие и снова открылся? -- Майк Клайн ( обсуждение ) 23:33, 2 января 2012 (UTC) [ ответить ]
Мы, кажется, сошлись почти на CAN шине. Либо переместите ее, откройте ее снова, чтобы увидеть, согласны ли мы, либо создайте новую для этого. Dicklyon ( talk ) 23:37, 2 января 2012 (UTC) [ ответить ]
Самым чистым будет, если кто-то откроет шину RM для CAN . Это позволит каждому высказать свое мнение по этому названию. -- Майк Клайн ( обсуждение ) 00:00, 3 января 2012 (UTC) [ ответить ]
Следующее обсуждение — это архивное обсуждение запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.

Результатом запроса на перемещение стало: страница перемещена . Vegaswikian ( обсуждение ) 06:24, 10 января 2012 (UTC) [ ответ ]

Контроллерная сеть → CAN шина –

Кажется, это лучший вариант, исходя из обсуждения выше. Тони (обсуждение) 00:40, 3 января 2012 (UTC) [ ответить ]

  • Да –  Dicklyon ( обсуждение ) 16:13, 6 января 2012 (UTC) [ ответить ]
  • Поддержка . Не решает вопрос о заглавных буквах, но решает вопрос о названии. –  Pnm ( talk ) 19:44, 6 января 2012 (UTC) [ ответить ]
Вышеуказанное обсуждение сохраняется как архив запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на этой странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.

СГ?

На схеме физического уровня узлы обозначены как SG1 SG2 .. SGn. Что такое "SG"? Это немецкая аббревиатура? Стоит ли заменить ее на ECU или Node (термины, используемые в других местах статьи). — Предыдущий неподписанный комментарий добавлен Hobsonlane ( обсуждение • вклад ) 16:15, 18 декабря 2011 (UTC) [ ответить ]

Почему расширенный фрейм данных?

Можете ли вы предоставить предысторию того, почему расширенные идентификаторы были добавлены к стандартному кадру, сделав его расширенным? Может быть, 11 бит было недостаточно? — Предыдущий неподписанный комментарий добавлен Pc 07 (обсуждение • вклад ) 06:15, 12 июня 2013 (UTC) [ ответить ]

Запрошенный ход 4

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

Результат запроса на перемещение: не перемещено . Jenks24 ( обсуждение ) 13:08, 11 июля 2014 (UTC) [ ответить ]


Шина CAN → Controller Area Network – чаще всего известна как CAN или Controller Area Network, а также как CAN bus, CAN Bus или CANbus. CAN обычно раскрывается в технических документах, и WP:NCA не приветствует аббревиатуры в названиях в таких случаях. Согласно WP:NOUN, мы пишем название с заглавной буквы, если подлежащее является именем собственным . Предыдущее продолжительное обсуждение того, как подлежащее пишется или не пишется с заглавной буквы в источниках, не имеет прямого отношения к делу. Если вам не нравятся заглавные буквы, пожалуйста, предоставьте обоснование для CAN как нарицательного существительного . Повторно включено . Jenks24 ( обсуждение ) 13:12, 3 июля 2014 (UTC) ~ KvnG 18:31, 25 июня 2014 (UTC) [ ответить ]

  • Поддержка (в принципе, не беспокойтесь о заглавных буквах) - обычно мы избегаем аббревиатур, если только аббревиатура на самом деле не более известна, чем ее полная форма ( USB , DVD ) Red Slash 23:43, 25 июня 2014 (UTC) [ ответить ]
  • Противостоять чрезмерному использованию заглавных букв – Согласно источникам книги, строчные буквы являются обычным явлением, и заглавные буквы необязательны, поэтому согласно MOS:CAPS , это должно быть Controller area network, если нам не нравится аббревиатура. Пожалуйста, просмотрите предыдущие запросы на перемещение. Dicklyon ( talk ) 00:02, 26 июня 2014 (UTC) [ ответить ]
    Я думаю, что WP:NOUN, а не MOS:CAPS — это то, что здесь применимо напрямую. Примеры того, как обрабатывается заглавная буква для похожих тем, можно найти здесь: Все страницы с заголовками, содержащими protocol ~ KvnG 14:19, 26 июня 2014 (UTC) [ ответить ]
    WP:NOUN поддерживает MOS:CAPS , говоря "Используйте строчные буквы, за исключением имен собственных". "Controller area network" не является именем собственным, хотя название протокола CAN может быть таковым. Dicklyon ( talk ) 23:49, 26 июня 2014 (UTC) [ reply ]
    Я полагаю, вы думаете, что сеть контроллеров похожа на локальную сеть . Я утверждаю, что сеть контроллеров — это особая и уникальная сетевая технология, похожая на интерфейс распределенных данных по оптоволокну . ~ KvnG 14:35, 27 июня 2014 (UTC) [ ответить ]
    Независимо от того, насколько это конкретно, официальное название протокола, похоже, CAN bus, и многие источники, и особенно лучше отредактированные источники, такие как книги, интерпретируют "controller area network" как общее и устанавливают его в нижнем регистре. Обычно это все доказательства, которые нам нужны, чтобы сделать вывод, что заглавные буквы не "необходимы" согласно MOS:CAPS . Dicklyon ( talk ) 15:24, 27 июня 2014 (UTC) [ ответить ]
    Так, поскольку название — CAN шина , мы должны называть ее сетью контроллеров ? Типичная википедия. Энди Дингли ( обсуждение ) 16:27, 27 июня 2014 (UTC) [ ответить ]
    Нет, но если вы хотите так называть, по крайней мере не переборщите с заглавными буквами; придерживайтесь MOS:CAPS . Оставить его на шине CAN — прекрасная альтернатива; я просто говорил, куда он пойдет, «если нам не понравится аббревиатура». Dicklyon ( talk ) 16:48, 27 июня 2014 (UTC) [ ответить ]
    @ Dicklyon : Если технология чаще всего упоминается как CAN bus , то я рад, что это предложение о перемещении отклонено. Я просмотрел ссылки и внешние ссылки, упомянутые в статье, и обнаружил, что 11 ссылаются на нее как на Controller Area Network (CAN) , 2 ссылаются на нее как на CAN Bus и 2 подтверждают, что используются оба термина. ~ KvnG 20:32, 27 июня 2014 (UTC) [ ответить ]
    @ Sbmeirow : прямо выше приведены мои доказательства того, что Controller Area Network (CAN) — это WP:COMMONNAME . ~ KvnG 14:10, 8 июля 2014 (UTC) [ ответить ]
  • Против - потому что нужно больше обсуждений и анализа других методов наименования статей "автобус" перед голосованием, вместо того, чтобы играть в пинг-понг "название статьи". См. шаблон ниже. • Sbmeirow • Обсуждение • 09:02, 26 июня 2014 (UTC) [ ответить ]
    Наименование, используемое в других статьях, не имеет большого значения. Здесь в первую очередь важно, под каким названием технология чаще всего известна в ссылках. Если это CAN или Controller Area Network, статья должна быть "Controller Areas Network". Если это CAN bus, CAN Bus или CANbus, то существующее название ("CAN bus") подойдет. (Это не следует путать с использованием заглавных букв в ссылках. Заглавные буквы - это проблема WP:MOS, а не проблема наименования, и они не обязательно соответствуют ссылкам.) ~ KvnG 14:19, 26 июня 2014 (UTC) [ ответить ]
    ээээ, наименование других статей, безусловно, имеет значение, иначе не было бы многочисленных рекомендаций в Википедии по этой теме. Я видел многочисленные вариации для "CAN" в журнальных статьях, таблицах данных, онлайн-статьях, блогах. Неважно, что вы выберете, кто-то будет ныть о том, что это не их предпочтительный способ наименования. Этот беспорядок вращается вокруг того, что исходная группа не выбрала лучшее название, которое не имело бы аббревиатуры, идентичной другому распространенному слову. Я не на 100% против переименования статьи, но я против переименования ее каждые пару лет. Вот почему я бы предпочел провести более длительное обсуждение плюсов и минусов каждого названия, а затем попытаться выяснить, какое из них лучше. Когда мы закончим, мы могли бы проголосовать за него и заархивировать все обсуждение для будущего использования, когда кто-то захочет переименовать его снова. • Sbmeirow • Обсуждение • 23:59, 26 июня 2014 (UTC) [ ответить ]
    Это звучит разумно, но, похоже, никто не проявил инициативу начать эту дискуссию. Я прочитал предыдущую дискуссию, прежде чем открыть это RM, и я решил использовать другой подход, и я призываю вас не увлекаться средствами и поддержать этот шаг, если вы считаете, что это улучшение существующего названия. ~ KvnG 14:35, 27 июня 2014 (UTC) [ ответить ]
  • CAN шина - ОБЩЕЕ НАЗВАНИЕ. Сеть контроллеров была бы особенно неуместна. Энди Дингли ( обсуждение ) 00:15, 27 июня 2014 (UTC) [ ответить ]
    @ Энди Дингли : можете ли вы предоставить доказательства того, что шина CAN — это WP:COMMONNAME . Ссылки из статьи указывают на то, что Controller Area Network (CAN) более распространена (см. мой ответ Dicklyon выше). ~ KvnG 17:12, 7 июля 2014 (UTC) [ ответить ]
    Можете ли вы предоставить доказательства, что это не так? • Sbmeirow • Talk • 21:49, 7 июля 2014 (UTC) [ ответить ]
    Вот несколько довольно убедительных доказательств того, что шина CAN является наиболее распространенной. Dicklyon ( обсуждение ) 03:51, 8 июля 2014 (UTC) [ ответить ]
    @ Dicklyon : это интересно, но в ссылках, которые я исследовал, первый случай указан как «Controller Area Network (CAN)», а в последующих ссылках используется аббревиатура («CAN»). Статьи, в которых используется «CAN bus», используют его неоднократно. Если вы посмотрите «CAN» в средстве просмотра Ngram, вы обнаружите, что это гигант, потому что он также используется для других целей . Средство просмотра Ngram просто подсчитывает общее количество случаев и недостаточно умно, чтобы выдавать точные результаты, учитывая, как «Controller Area Network» и «CAN» используются в ссылках, которые я исследовал. ~ KvnG 14:10, 8 июля 2014 (UTC) [ ответить ]
    Конечно, вы не захотите использовать n-граммы, чтобы рассмотреть только CAN. Но это показывает, что "CAN bus" гораздо более распространено, чем "Controller Area Network", а также что строчная форма не является редкостью. Я согласен с вами, что "Controller Area Network (CAN)" очень распространено, так как люди обычно пишут с заглавной буквы при образовании аббревиатур. Это и частое появление в заголовках, заголовках и таблицах объясняют большую часть использования заглавных букв. Остальное делают люди, которые думают об этом как о собственном имени или предпочитают писать заглавными буквами для акцента, но это не означает, что мы должны делать то же самое, в свете MOS:CAPS . Dicklyon ( talk ) 03:21, 9 июля 2014 (UTC) [ reply ]
    Я думаю, вы, возможно, не поняли мою мысль. Источники, которые используют "CAN bus", используют эту фразу для всех случаев. Источники, которые используют "Controller Area Network", используют ее один раз, а затем используют "CAN" для дальнейших случаев. Я хочу сказать, что n-gram viewer слепо подсчитывает случаи и не обязательно даст точное сравнение в этом случае. ~ KvnG 13:45, 9 июля 2014 (UTC) [ ответить ]
Вышеуказанное обсуждение сохраняется как архив запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на этой странице обсуждения или в обзоре перемещения . Дальнейшие правки в этот раздел вноситься не должны.

Ссылки на другие языки отсутствуют (Wikidata) — Пожалуйста, помогите

Понятия не имею, в чем причина, но ссылки на другие языки исчезли. Я вижу их нормально, например, на de:Controller Area Network, но не здесь. Может ли кто-нибудь помочь? Тони Мах ( обс .) 12:21, 18 августа 2015 (UTC) [ ответить ]

ИСО 11898-2:2016

ISO 11898-2:2016 теперь существует. И насколько я слышал, он поддерживает CAN FD до 12 Мбит/с. — Предыдущий неподписанный комментарий добавлен 62.119.168.113 ( обсуждение ) 08:10, 11 января 2018 (UTC) [ ответить ]

Определение «Автобус» кажется слишком конкретным

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

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

Есть мнения?

-- Wrev ( обсуждение ) 08:58, 21 января 2019 (UTC) [ ответить ]

В настоящее время в качестве wl лидирует шина транспортного средства . Это необходимо сохранить. Я не возражаю против чего-либо, расширяющего это с помощью нетранспортных приложений, но это должно сохранить шину транспортного средства в лидирующей позиции. Энди Дингли ( обсуждение ) 11:45, 21 января 2019 (UTC) [ ответить ]

Добавить раздел с описанием физического уровня Single Wire CAN (SAE J2411)

Спецификация SAE J2411 (на момент написания статьи в Википедии не упоминалась) определяет физический уровень Single Wire (плюс заземление) для шины CAN.

Микросхемы и устройства драйверов шины Single Wire CAN уже широко используются.

Ссылки
  • Ссылка SAE J2411
  • Однопроводная CAN-сеть для транспортных средств – SAE J2411 – Стандарт

диаграмма под названием «Низкоскоростная отказоустойчивая сеть CAN». ISO 11898-3

Похоже, что узлы соединены случайным образом, иногда h с l, а иногда h с h.

Сколько блоков управления он может поддерживать?

«может иметь до 70 электронных блоков управления (ЭБУ) для различных подсистем.[7]

Есть ли разумный предел? 70 требует 6+ бит (т. е. 7 или больше). Есть ли что-то еще, что ограничивает это 70? — Предыдущий неподписанный комментарий добавлен WithGLEE ( talk • contribs ) 16:25, 8 декабря 2020 (UTC) [ ответить ]

Нет ограничений со стороны протокола. Есть ограничения по используемому трансиверу, потому что выбранный трансивер может управлять только определенным количеством тока, и поэтому может быть подключено только определенное количество узлов. Самый слабый трансивер определяет используемые узлы в сети. Также может быть ограничение по протоколу более высокого уровня, например, 64 в DeviceNet, 127 в CANopen. MisterTS ( talk ) 19:39, 25 апреля 2021 (UTC) [ ответить ]

Непонятно

Это кажется непонятным (в подразделе « Вставка битов »):

«Неправильно использовать CRC для иллюстрации подстановки битов».

Что имеется в виду (если имеется)? Что значение CRC недействительно для примера сообщения CAN (что приводит к кадру ошибки)? Где появляется бит-стаффинг (он также происходит в поле CRC)?

-- Мортенс ( обсуждение ) 19:56, 12 октября 2021 (UTC) [ ответить ]

Приложения

В этой статье содержится много технической информации, но практически нет практической информации по использованию.

Какие элементы на транспортном средстве обычно контролируются шиной CANbus? Какие элементы обычно не контролируются шиной? Линии питания в разъемах D питают только приемопередатчики+контроллеры или они также питают потребителей электроэнергии (например, индикаторную лампу)?

Если для питания устройства (например, ламп дальнего света) требуется отдельный источник питания, используется ли отдельная вилка/розетка для подключения устройства к источнику питания? Или некоторые производители объединяют кабель питания с шиной и используют более мощную вилку/розетку, чтобы для каждого устройства требовался только один штекер и один гнездовой разъем?

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

Спасибо. FreeFlow99 ( обсуждение ) 11:31, 12 ноября 2021 (UTC) [ ответить ]

CAN Bus не может обрабатывать данные

«Шина CAN также принимает сигналы от датчика дождя для включения заднего стеклоочистителя при движении задним ходом»

Для новых студентов CAN Bus это может быть очень запутанным. Сама CAN Bus не может принимать никаких входных данных или обрабатывать информацию. 2003:E5:DF11:9800:71E6:AD9A:BF7D:B57A (обсуждение) 08:26, 6 мая 2022 (UTC) [ ответить ]

Разъяснение

@ Constant314 : Вы не объяснили, почему вы вернули меня. Я думал, что дал адекватное объяснение того, что я делаю в своем резюме правок. Правка, которая добавила тег «необходимо разъяснение», на самом деле преуспела в том, что сделала весь отрывок гораздо менее понятным для читателя. Spinning Spark 23:42, 10 октября 2022 (UTC) [ ответить ]

Я не знаю, что там произошло. Я не собирался делать этот возврат. Все, что я могу предположить, это то, что указатель просто оказался на возврате, и что-то упало на мышь. Это был один из таких дней. В любом случае, я отменил свой возврат. Ура. Constant 314 ( talk ) 01:07, 11 октября 2022 (UTC) [ ответить ]
Спасибо, без проблем. Я сам допустил немало глупых ошибок в Википедии, так что мне не на что жаловаться. Spinning Spark 08:48, 11 октября 2022 (UTC) [ ответить ]

Отличайте сообщения от фреймов

Насколько я понимаю, статья путает кадры (основные единицы передачи) с сообщениями (информация, передаваемая через Data Frame). Многие ссылки на сообщения следует заменить на кадры, среди прочих разъяснений. ★NealMcB★ ( talk ) 18:16, 30 декабря 2023 (UTC) [ ответить ]

Опишите файлы DBC, простые базы данных для определения форматов сообщений, целей, содержимого и т. д.

Файлы CAN DBC, по-видимому, важны для работы с сообщениями шины CAN. ★NealMcB★ ( обсуждение ) 18:19, 30 декабря 2023 (UTC) [ ответ ]

Это часть CANopen . Это уровень над этой статьей, который является физическим уровнем. Alexceltare2 ( talk ) 10:38, 26 апреля 2024 (UTC) [ ответить ]

Новый лидер

Я написал новый раздел лида, суммируя, по моему мнению, ключевые моменты CAN. Оставленный в старом лиде, он содержит более плотную информацию.  Берт Харрис ( обсуждение ) 23:14, 2 ноября 2024 (UTC) [ ответить ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:CAN_bus&oldid=1255062764"