Alt@ir (06.04.2023 09:20, просмотров: 222) ответил =AlexD= на Сначала, мил человек, нужно доказать что высокоприоритетные
сообщения не заблокируют шину полностью - при любой ситуации (в
т.ч. аварийной) и при любой конфигурации сети. Гарантировано, а не
"помолясь и с божьей помощью".-
- Мы всё ещё говорим о гарантированных на уровне архитектуры
времянках, или уже о разруливании полной катастрофы? - =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)