Cкpипaч, пророк (01.04.2023 22:32, просмотров: 164) ответил Alt@ir на А на 485 приоритетность на аппаратном уровне не настроить.... но не любой ценой.
-
- На шине 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)