-
- Так это не так. CAN как минимум в два раза эффективнее модбаса по
занимаемой полосе и очень много эффективнее по времени реакции - Alt@ir(01.04.2023 22:24)
- А как CAN себя ведет при близкой к 100% нагрузке на шину? Ась? 8) - Cкpипaч(01.04.2023 22:27)
- у меня в кене идет обновление прошивки с низкоприоритетными сообщениями которые забивают все свободное время на шине. Загрузка 100% при этом боевая работа не останавливается и идет без проблем. - Nikolay801_(03.04.2023 16:20)
- В практике не знаю. В теории приоритетные сообщения должны
проходить, а при неумении и писюн подвержен травмам. Там же все
гибко настраивается. Это же не модбас - Alt@ir(01.04.2023 22:29)
- Подсказываю, ляжет. А на 485-м есть не только Modbus. Cкpипaч(125 знак., 01.04.2023 22:29)
- CANopen предусматривает любой вариант. И так, что никто не вякнет
без команды тоже можно. - Alt@ir(01.04.2023 22:52)
- Ткни пальцем, пожалуйста. Не помню я такого режима в нем. - Cкpипaч(01.04.2023 23:09)
- Он говорит про третий уровень OSI. Профилями slave занимается
master. Один из режимов - отвечай только в ответ на свой запрос.
Это программно делается, CAN контроллер тут не при чем. Я не знаю
почти ничего про CANOpen, но наверное этот так. - Evgeny_CD(02.04.2023 14:42)
- На нижнем уровне CAN есть такой запрос на передачу сообщения, называется remote frame, опрос на нём реализовать можно. Только его почти не используют, иногда даже не реализуют. - ЫЫyкпy(02.04.2023 16:25)
- Ниже коллега уже все разъяснил. Да, с CANopen можно достичь полного заполнения шины. Признаю. Но это не
основополагающее свойство, а экзотика. Возможность ошибки
прикладного программиста и "затык приоритетов" - возможен. Лично я
не стал бы закладывать в свой проект CAN-шину с более чем 30%
заполнением полосы пропускания. Cкpипaч(639 знак., 02.04.2023 15:06)
- 30% AndreasW(203 знак., 03.04.2023 08:45)
- Хорошо написано, спасибо! M$ в свое время предлагала защиту от e-mail спама на основе обязательности неких сложных вычислений перед отправкой мыла. Если ты шлешь мыло по делу, то тебе не надо слать 10к писем с одного ПК в минуту. Спамеры отсосут. Здесь тот же принцип, но более хитро вплетенный в ткань реальности - Evgeny_CD(02.04.2023 15:36)
- Работа только через SDO без PDO.. Т.е. полностью как модбас. Только
ответ на конкретный запрос мастера к конкретному устройству и
конкретному регистру. - Alt@ir(02.04.2023 04:34)
- ...только описание модбас занимает одну страницу :) Проблема не в
низкой, как вы сказали, квалификации, проблема в попытке создать целую область компетенции, там где достаточно одной страницы текста. Cкpипaч(364 знак., 02.04.2023 08:08 - 08:11)
- Чуток культпросвета. Нужно различать физическую шину CAN (1 и 2
уровень OSI) и протокольную надстройку CANopen (3,4,5,6 уровни
OSI). В ПЛК стандартно используют CAN шину и почти всегда на ней
поднят мастер CANopen. Вот как раз протокол CANopen и определяет
кому что можно. Грубо можно сказать что CANopen это модбас на
стероидах. Ввели возможность приоритетезации, network management и
различные способы взаимодействия элементов сети: request driven,
time driven, event driven, Alt@ir(12 знак., 02.04.2023 10:28)
- Это понятно. Как увязать два сделанных кем-то другим устройства - понятно. И это не сильно сложнее чем Modbus ;-) Cкpипaч(484 знак., 02.04.2023 10:50)
- Ну мне пришлось. Я делал абсолютный энкодер для задач движения. Там
CAN - самый дешёвый вариант, ибо ПЛК с SSI или BISS экзотика, а
если надо три-пять таких интерфейсов - вообще беда. - Alt@ir(02.04.2023 10:54)
- SSI - экзотика? ))) Дружище, лет 20 использую энкодеры во всех их
проявлениях. SSI как у самих энкодеров, так и у контроллеров сплошь
и рядом. Ну а учитывая что, как правило, являюсь и разработчиком
контролера (норм вещи, не светиком моргнуть), то SSI там есть
просто всегда. Нахера сюда тащить CAN? - POV(03.04.2023 21:43)
- Я в Омске (хоть и за МКАДом, но все же миллионник) пытался найти
хоть что то с SSI. И никто про него не слышал. Ни в университетах
на профильных кафедрах, ни на заводах (кроме нефтезавода - туда
хрен попадешь), ни в фирмах про АСУТП. Даже про КАН только слышали. Но никто не применяет, и КАНопен соответственно тоже не знает.
Пришлось самому суппостатские манускрипты вдумчиво изучать до тех
пор, пока не заработало. - Alt@ir(04.04.2023 09:11)
- Ок, а теперь плёвая задача - продать то что заработало (помимо
основного заказчика). Нет, ты молодец, конечно, задачу выполнил, но
это такой себе предмет для гордости - твоё повышение компетенции в
узкой предметной области не факт что будет сильно востребовано. - =AlexD=(06.04.2023 06:47)
- Я молодец, это факт. ;-) - Alt@ir(06.04.2023 09:27)
- Ок, а теперь плёвая задача - продать то что заработало (помимо
основного заказчика). Нет, ты молодец, конечно, задачу выполнил, но
это такой себе предмет для гордости - твоё повышение компетенции в
узкой предметной области не факт что будет сильно востребовано. - =AlexD=(06.04.2023 06:47)
- Я в Омске (хоть и за МКАДом, но все же миллионник) пытался найти
хоть что то с SSI. И никто про него не слышал. Ни в университетах
на профильных кафедрах, ни на заводах (кроме нефтезавода - туда
хрен попадешь), ни в фирмах про АСУТП. Даже про КАН только слышали. Но никто не применяет, и КАНопен соответственно тоже не знает.
Пришлось самому суппостатские манускрипты вдумчиво изучать до тех
пор, пока не заработало. - Alt@ir(04.04.2023 09:11)
- Норм. Этот интерфейс достаточно распространен. Особенно для данной задачи. Но если у вас в руках молоток, не стоит поддаваться воображению, вокруг не только гвозди :) Cкpипaч(55 знак., 02.04.2023 10:59)
- SSI - экзотика? ))) Дружище, лет 20 использую энкодеры во всех их
проявлениях. SSI как у самих энкодеров, так и у контроллеров сплошь
и рядом. Ну а учитывая что, как правило, являюсь и разработчиком
контролера (норм вещи, не светиком моргнуть), то SSI там есть
просто всегда. Нахера сюда тащить CAN? - POV(03.04.2023 21:43)
- Ну мне пришлось. Я делал абсолютный энкодер для задач движения. Там
CAN - самый дешёвый вариант, ибо ПЛК с SSI или BISS экзотика, а
если надо три-пять таких интерфейсов - вообще беда. - Alt@ir(02.04.2023 10:54)
- Это понятно. Как увязать два сделанных кем-то другим устройства - понятно. И это не сильно сложнее чем Modbus ;-) Cкpипaч(484 знак., 02.04.2023 10:50)
- Задачи бывают разные. Где то и модбас не нужен. Немцы отнюдь не
дураки, и создали и CAN и CANopen с вполне конкретными целями.
Модбас, например, не может решать задачи motion control, a CAN
может. Это реально область компетенций, которая должна быть освоена
для использования. Но она даёт некоторые преимущества. Не всегда
оно надо, но это и не значит что раз надо что то изучить, то это
шляпа. - Alt@ir(02.04.2023 08:10)
- Вы спросили, почему CANopen не мейнстрим. А так, да, Волга впадает
в Балтийское море. - Cкpипaч(02.04.2023 08:12)
- Так я получил ответ. Лень и низкая квалификация. Т.е. причины не технические, а организационные. Alt@ir(9 знак., 02.04.2023 08:14)
- Вы спросили, почему CANopen не мейнстрим. А так, да, Волга впадает
в Балтийское море. - Cкpипaч(02.04.2023 08:12)
- Чуток культпросвета. Нужно различать физическую шину CAN (1 и 2
уровень OSI) и протокольную надстройку CANopen (3,4,5,6 уровни
OSI). В ПЛК стандартно используют CAN шину и почти всегда на ней
поднят мастер CANopen. Вот как раз протокол CANopen и определяет
кому что можно. Грубо можно сказать что CANopen это модбас на
стероидах. Ввели возможность приоритетезации, network management и
различные способы взаимодействия элементов сети: request driven,
time driven, event driven, Alt@ir(12 знак., 02.04.2023 10:28)
- ...только описание модбас занимает одну страницу :) Проблема не в
низкой, как вы сказали, квалификации, проблема в попытке создать целую область компетенции, там где достаточно одной страницы текста. Cкpипaч(364 знак., 02.04.2023 08:08 - 08:11)
- Он говорит про третий уровень OSI. Профилями slave занимается
master. Один из режимов - отвечай только в ответ на свой запрос.
Это программно делается, CAN контроллер тут не при чем. Я не знаю
почти ничего про CANOpen, но наверное этот так. - Evgeny_CD(02.04.2023 14:42)
- Ткни пальцем, пожалуйста. Не помню я такого режима в нем. - Cкpипaч(01.04.2023 23:09)
- А на 485 приоритетность на аппаратном уровне не настроить. - Alt@ir(01.04.2023 22:30)
- С чего вдруг?! Мастер ВНУТРИ СЕБЯ абсолютно любую приоритетность
настроит 8) Но она (приоритетность) и нахер не упала в задачах
управления, вот в чем ключ. - Cкpипaч(01.04.2023 22:32)
- На шине CAN приоритетное устройство задавит все остальные и донесет
свое сообщение до мастера. Всегда. В 485 этого нет. Как назначить
сетевое взаимодействие - это вопрос проектировщика. Но с КАНом этих
инструментов сильно больше - Alt@ir(01.04.2023 22:37)
- Сначала, мил человек, нужно доказать что высокоприоритетные
сообщения не заблокируют шину полностью - при любой ситуации (в
т.ч. аварийной) и при любой конфигурации сети. Гарантировано, а не
"помолясь и с божьей помощью". - =AlexD=(06.04.2023 06:38)
- Хитрые немцы все продумали. В Кане нельзя заблокировать шину. Как
только 127 высокоприоритетных пакетов не смогут получить АСК -
трансивер физически освободит шину. На протокольном уровне тоже
есть несколько механизмов арбитража - Alt@ir(06.04.2023 09:20)
- Мы всё ещё говорим о гарантированных на уровне архитектуры
времянках, или уже о разруливании полной катастрофы? - =AlexD=(06.04.2023 09:35)
- Есть такие времянки в КАНе. Есть. Гарантированные. Именно вокруг
этих гарантированных времянок он и создавался. - Alt@ir(06.04.2023 09:37)
- Да, есть, при резервировании полосы пропускания. А далее как бог
даст, ну или крутить конфиги превращая его из асинхронной системы в
синхронную. Решение годное, но не ультимативное. - =AlexD=(06.04.2023 09:41)
- Приоритетный пакет ВСЕГДА пройдет. (но после, конечно) Шина хоть и
асинхронная, но синхронная :-) Я имею ввиду, что даже если шина
занята и много нод решило что то передать, то по окончании текущего
пакета все равно все начнут передавать синхронно и арбитраж
выиграет самая приоритетная нода. - Alt@ir(06.04.2023 09:46)
- Я знаю как работает CAN, я его юзал. И скажу тебе что приоритеты -
весьма неоднозначная тема. Например для некоторого не особо
приоритетного трафика тем не менее важна стабильность доставки.
Т.е. джиттер возможен, но не должен превышать определённого
значения. Как тут расставить приоритеты? В твоём энкодере,
например. Особенно если их туча на одной шине. - =AlexD=(06.04.2023 09:54)
- Энкодеров не туча, а вполне определенное количество. Проектировщик
более верхней системы должен понимать что как и что чудес не
бывает. И в CANopen есть всякие механизмы, времянки и правила. Их
нужно знать. Необходимость иметь некоторую квалификацию это,
безусловно, недостаток CAN. - Alt@ir(06.04.2023 10:07)
- И? Напомнить тебе, сколько таких "КАНов" существует в мире? :)
Кому-то действительно именно этот протокол нужен, и тот уже его
изучил. Мне - нет. Cкpипaч(1072 знак., 06.04.2023 10:28 - 10:32)
- Modbus RTU заставить работать некорректно да вообще без проблем.
Мастером в большинстве случаев работает либо PC либо SOC. В обоих
случаях проверять строгие тайминги RTS мастер неспособен.
Формировать защитный интервал 3,5T мастер тоже не может потому что
ни 16550 UART ни USB-485 конверторы этого аппаратно не умеют а
софтверно писюку отрабатывать строгий тайминг не по силам. Таким
образом оно работает чисто за счет растяжек. А 485 на растяжках это еще хуже чем CAN. 3m(84 знак., 06.04.2023 12:29)
- Точно 3,5Т выдерживать и не надо, надо больше 3,5Т. А это решаемо. Передал пакет и сразу на приём уходи. - symbions(06.04.2023 14:12)
- Может и изменило. А вот уверенно поселиться в ПЛК не смогло. Я не
работаю с АСУТП, но изучение номенклатуры самого доступного
показало, что после RS-485 CAN в виде CANopen - первый парень на
деревне. Эзернет - еще менее полевая шина чем CAN. - Alt@ir(06.04.2023 10:31)
- а можно позанудствовать?)) 485 - ето физ.уровень, а что бегаеть
поверьх его - лишь Будда знаеть, тогда как CAN - ето и физика и
лирика, сиречь протоколы
сионских мудрецоввполне определённыя. - Alex68(06.04.2023 16:30) - С этим не спорю. 99% рынка занимает rs485, 0,5% -CAN, остальное - все остальные :))) - Cкpипaч(06.04.2023 10:33)
- а можно позанудствовать?)) 485 - ето физ.уровень, а что бегаеть
поверьх его - лишь Будда знаеть, тогда как CAN - ето и физика и
лирика, сиречь протоколы
- Modbus RTU заставить работать некорректно да вообще без проблем.
Мастером в большинстве случаев работает либо PC либо SOC. В обоих
случаях проверять строгие тайминги RTS мастер неспособен.
Формировать защитный интервал 3,5T мастер тоже не может потому что
ни 16550 UART ни USB-485 конверторы этого аппаратно не умеют а
софтверно писюку отрабатывать строгий тайминг не по силам. Таким
образом оно работает чисто за счет растяжек. А 485 на растяжках это еще хуже чем CAN. 3m(84 знак., 06.04.2023 12:29)
- И? Напомнить тебе, сколько таких "КАНов" существует в мире? :)
Кому-то действительно именно этот протокол нужен, и тот уже его
изучил. Мне - нет. Cкpипaч(1072 знак., 06.04.2023 10:28 - 10:32)
- Энкодеров не туча, а вполне определенное количество. Проектировщик
более верхней системы должен понимать что как и что чудес не
бывает. И в CANopen есть всякие механизмы, времянки и правила. Их
нужно знать. Необходимость иметь некоторую квалификацию это,
безусловно, недостаток CAN. - Alt@ir(06.04.2023 10:07)
- Я знаю как работает CAN, я его юзал. И скажу тебе что приоритеты -
весьма неоднозначная тема. Например для некоторого не особо
приоритетного трафика тем не менее важна стабильность доставки.
Т.е. джиттер возможен, но не должен превышать определённого
значения. Как тут расставить приоритеты? В твоём энкодере,
например. Особенно если их туча на одной шине. - =AlexD=(06.04.2023 09:54)
- Приоритетный пакет ВСЕГДА пройдет. (но после, конечно) Шина хоть и
асинхронная, но синхронная :-) Я имею ввиду, что даже если шина
занята и много нод решило что то передать, то по окончании текущего
пакета все равно все начнут передавать синхронно и арбитраж
выиграет самая приоритетная нода. - Alt@ir(06.04.2023 09:46)
- Да, есть, при резервировании полосы пропускания. А далее как бог
даст, ну или крутить конфиги превращая его из асинхронной системы в
синхронную. Решение годное, но не ультимативное. - =AlexD=(06.04.2023 09:41)
- Есть такие времянки в КАНе. Есть. Гарантированные. Именно вокруг
этих гарантированных времянок он и создавался. - Alt@ir(06.04.2023 09:37)
- Мы всё ещё говорим о гарантированных на уровне архитектуры
времянках, или уже о разруливании полной катастрофы? - =AlexD=(06.04.2023 09:35)
- Хитрые немцы все продумали. В Кане нельзя заблокировать шину. Как
только 127 высокоприоритетных пакетов не смогут получить АСК -
трансивер физически освободит шину. На протокольном уровне тоже
есть несколько механизмов арбитража - Alt@ir(06.04.2023 09:20)
- в оригинальной бошевской спецификации нет гарантии доставки.
Приоритетное сообщение может всех обойти, но гарантии доставки нет,
мастер может не узнать. Точно как в анекдоте "с моей стороны пули
вылетели..." - Nikolay801_(03.04.2023 16:37)
- Но мастер может повторить. Он же сразу знает что пакет не дошел. - Alt@ir(03.04.2023 16:54)
- НЕ ЗНАЕТ. Nikolay801_(102 знак., 03.04.2023 18:50)
- Точно? Он разве не рецессивный? Спорить не буду, почитаю доку сначала 😃 - Alt@ir(03.04.2023 18:52)
- НЕ ЗНАЕТ. Nikolay801_(102 знак., 03.04.2023 18:50)
- Но мастер может повторить. Он же сразу знает что пакет не дошел. - Alt@ir(03.04.2023 16:54)
- Ты не слышишь. Возня с приоритетами - нахер никому не нужна, в
промавтоматике. От слова совсем. Почитай что топикстартер пишет,
тут программисты хотят все в одну бошку залить. Вообще все, весь
завод :) Cкpипaч(308 знак., 01.04.2023 22:43)
- Да все я слышу. И пытаюсь понять почему великолепный CANopen не
используется в промавтоматике. Пока слышу причину - низкая
квалификация. Штош, это тоже причина. - Alt@ir(01.04.2023 22:46)
- Почему не используется.... Очень даже используется. В недавно полученных нами несколько лет назад итальянских линиях на нём связи реализованным между щитами. Работает нормально. Да и в современных китайцах есть. - CeneriAM(02.04.2023 12:54)
- ну. имею пред глазами промоборудование - печатные машины. там хренова туча датчиков и енкодеров на canopen сидит. все в риал-тайме робит. так шо используют творение бошевское. - Alex68(01.04.2023 23:24)
- Угу. Никто не хочет играть в бирюльки, пишут дубовый прикладной код, вместо того чтобы настрогать приоритетов и заебаться их настраивать (я с приоритетами вдоволь наигрался на втором курсе, досвидания, про низкую квалификацию грузи своих клиентов). - Cкpипaч(01.04.2023 22:49)
- Да все я слышу. И пытаюсь понять почему великолепный CANopen не
используется в промавтоматике. Пока слышу причину - низкая
квалификация. Штош, это тоже причина. - Alt@ir(01.04.2023 22:46)
- Сначала, мил человек, нужно доказать что высокоприоритетные
сообщения не заблокируют шину полностью - при любой ситуации (в
т.ч. аварийной) и при любой конфигурации сети. Гарантировано, а не
"помолясь и с божьей помощью". - =AlexD=(06.04.2023 06:38)
- На шине CAN приоритетное устройство задавит все остальные и донесет
свое сообщение до мастера. Всегда. В 485 этого нет. Как назначить
сетевое взаимодействие - это вопрос проектировщика. Но с КАНом этих
инструментов сильно больше - Alt@ir(01.04.2023 22:37)
- С чего вдруг?! Мастер ВНУТРИ СЕБЯ абсолютно любую приоритетность
настроит 8) Но она (приоритетность) и нахер не упала в задачах
управления, вот в чем ключ. - Cкpипaч(01.04.2023 22:32)
- CANopen предусматривает любой вариант. И так, что никто не вякнет
без команды тоже можно. - Alt@ir(01.04.2023 22:52)
- Подсказываю, ляжет. А на 485-м есть не только Modbus. Cкpипaч(125 знак., 01.04.2023 22:29)
- А как CAN себя ведет при близкой к 100% нагрузке на шину? Ась? 8) - Cкpипaч(01.04.2023 22:27)
- Так это не так. CAN как минимум в два раза эффективнее модбаса по
занимаемой полосе и очень много эффективнее по времени реакции - Alt@ir(01.04.2023 22:24)