caxapa.ru :: В практике не знаю. В теории приоритетные сообщения должны проходить, а при неумении и писюн подвержен травмам. Там же все гибко настраивается. Это же не модбас

Alt@ir (01.04.2023 22:29, просмотров: 178) ответил Cкpипaч на А как CAN себя ведет при близкой к 100% нагрузке на шину? Ась? 8)

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

Ответить

- Подсказываю, ляжет. А на 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)
        
        -> Evgeny_CD(1 знак., 02.04.2023 18:29, ссылка)
        
        Ниже коллега уже все разъяснил. Да, с 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)
        
        Норм. Этот интерфейс достаточно распространен. Особенно для данной задачи. Но если у вас в руках молоток, не стоит поддаваться воображению, вокруг не только гвозди :) Cкpипaч(55 знак., 02.04.2023 10:59)
        
        Задачи бывают разные. Где то и модбас не нужен. Немцы отнюдь не дураки, и создали и 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)
        
        Если называть "ленью" мой прямой запрет (как директора), а "низкой квалификацией" - отказ тратить деньги на специалистов "абстрактных знаний", то да. - Cкpипaч(02.04.2023 08:21)
  - А на 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)
        
        не спора ради, но информации для - наблюдаю множество ~~миров~~ машин, несущих слово в массы - отдельные части тех творений сумрачного тевтонского гения совокуплены посредством бошевского творенья. - Alex68(06.04.2023 16:01)
        
        Ладно, урежу осетра, 6% рынка автоматизации. Это много. Не торгуйтесь. Всего в ходу, вангую, порядка двухсот различных протоколов "полевых шин". - Cкpипaч(06.04.2023 16:04)
        
        в оригинальной бошевской спецификации нет гарантии доставки. Приоритетное сообщение может всех обойти, но гарантии доставки нет, мастер может не узнать. Точно как в анекдоте "с моей стороны пули вылетели..." - 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)
        
        Ты не слышишь. Возня с приоритетами - нахер никому не нужна, в промавтоматике. От слова совсем. Почитай что топикстартер пишет, тут программисты хотят все в одну бошку залить. Вообще все, весь завод :) 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)

Кибернетика, автоматика, протоколы