[AlexandrY 3]

48 minutes ago, syoma said:

 либо будет принято всеми активными узлами в сети, либо не будет принято ни одним из них. 

Здесь ошибка.
Мы можем знать что принял хотя бы один, но не все. Т.е. нет никаких средств на физическом уровне чтобы  убедится в приеме пакета именно всеми.   
Но есть бит запроса на передачу, который вызывает автоматом ответ слэйвов.
Мастер пожет посылать пакеты с таким битом и должен принять все подтверждения. Вот это вызовет флуд. 
Т.е. в CAN-е нет широкополосных передач с гарантированной доставкой. 
Новизна в идеологии CAN  - это независимые каналы peer-to-peer.  

А схема "издатель-подписчик" для CAN-а не годится поскольку на самом деле ее надо называть "издатели-подписчики", и это вызовет в CAN-е флуд.  

[Алексей Васильевич 0]

2 часа назад, HardEgor сказал:

Элементарно - посылаешь запрос и получаешь ответ :)

Зависит от скорости интерфейса

Посылаешь 1000 запросов и получаешь один ответ через 30 секунд у лучшем случае, при условии что слейв не задерживает а просто тратит время на чтение и ответ. 

Теоретически CAN будет в сотни раз быстрее работать в сравнение с предложной вами схемой.

[syoma 1]

15 minutes ago, AlexandrY said:

Мы можем знать что принял хотя бы один, но не все. Т.е. нет никаких средств на физическом уровне чтобы  убедится в приеме пакета именно всеми. 

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

Не?

Quote

Но есть бит запроса на передачу, который вызывает автоматом ответ слэйвов.
Мастер пожет посылать пакеты с таким битом и должен принять все подтверждения. Вот это вызовет флуд. 

RTR? Не него вроде отвечают автоматом только те, у кого идентификатор совпадает с этим фреймом. Т.е. далеко не все.

[Алексей Васильевич 0]

Доставка "всегда" даже при плохой связи через трансиверы ? 

[Eddy_Em 1]

Вот, кстати, проблема с распознаванием отсутствия слушателей на линии — большое препятствие в использовании активных CAN-шлюзов (которые внутри себя данные буферизуют и отправляют). Я так и не придумал, как по-простому эту проблему решить... Ведь  наличие шлюза на шине означает, что всегда будет хотя бы один читатель. Разве что выдумывать в протоколе "широковещательные" сообщения на определенный ID, чтобы нужные слейвы отвечали…

[HardEgor 71]

22 минуты назад, Алексей Васильевич сказал:

Посылаешь 1000 запросов и получаешь один ответ через 30 секунд у лучшем случае, при условии что слейв не задерживает а просто тратит время на чтение и ответ. 

Что-то у вас не так. 1000 запросов - это по одному запросу в один slave? Какая у вас скорость? На 9600 тысяча 2-байтовых пакетов запроса с защитным интервалом 1мс улетят за несколько секунд, но не 30-же.

Но если вам надо опросить всех, то для этого делается групповая команда, которую принимают и начинают обрабатывать все слейвы. А ответы начинают последовательно поступать по факту освобождения линии.

Надеетесь что в CAN другая модуляция?

[Eddy_Em 1]

36 minutes ago, HardEgor said:

Но если вам надо опросить всех, то для этого делается групповая команда, которую принимают и начинают обрабатывать все слейвы. А ответы начинают последовательно поступать по факту освобождения линии.

Не факт, у меня так на STM32F042 сделать не получилось: что-то я накриворучил, и если одновременно пять "слейвов" шлют данные, то от трех-четырех запросто пакеты теряются (у меня нет подтверждения приема в протоколе - если надо, "мастер" просто еще раз "слейв" опросит).

[jcxz 218]

9 часов назад, Алексей Васильевич сказал:

Перед тем как отправить пакет в DMA создаю команду на прием пакета ЗАДАННОЙ длинны, калбек отправки переключает драйвер на прием. Если пакет ответа будет короче , калбек приема не отработает , опрос на время остановится, а сама ошибка будет обработана в отбельном потоке, таких ошибок может быть десятки в секунду падает скорость обмена. 

Ну вот, как я и подозревал - у Вас неправильная архитектура ПО.

Во-первых: нужно завершать RX-DMA-транзакцию не только по размеру, но и по таймауту.

Во-вторых: мухи - отдельно, котлеты - отдельно прикладные кадры данных - отдельно, блоки байтов принимаемые из UART - отдельно.

Здесь на форуме уже не раз обсуждалась эта тема. Воспользуйтесь поиском.

 

9 часов назад, Алексей Васильевич сказал:

 - В одном потоке главного цикла невозможно параллельно подключить LAN, а работа основной программы останавливает опрос,

- В нескольких потоках с равным приоритетом скорость обмена падает в 3 раза    

- В нескольких потоках с приоритетом обмена , не работает USB и LAN , обновление экрана и клавиатура отвечает с задержкой в несколько секунд.

Это не "невозможно", это Вы не смогли. Всё это возможно. Но лучше использовать РТОС, а не суперцикл.

5 часов назад, syoma сказал:

Чисто физически 1000 CAN трансиверов на одну сеть не повесить, поэтому нужны репитеры, которые бы разделяли сети на сегменты. Тогда можно и скорость повысить

А как в этом случае получать подтверждения (ACK-и) от слэйвов? Через цепочку репитеров.

3 часа назад, HardEgor сказал:

Да, еще приличную задержку может добавить гальваноразвязка с обеих концов.

Ну кто-ж мешает использовать ADUM-ы и избежать задержки?

[HardEgor 71]

31 минуту назад, Eddy_Em сказал:

Не факт, у меня так на STM32F042 сделать не получилось: что-то я накриворучил, и если одновременно пять "слейвов" шлют данные, то от трех-четырех запросто пакеты теряются (у меня нет подтверждения приема в протоколе - если надо, "мастер" просто еще раз "слейв" опросит).

Зачем одновременно? Есть адрес устройства ADDR , в самом простом случае, при одинаковом размере пакета Nbit,  вычисляйте задержку начала передачи каждого устройства:

(ADDR-1) + 1000*Nbit/speed, ms

 

28 минут назад, jcxz сказал:

Это не "невозможно", это Вы не смогли. Всё это возможно. Но лучше использовать РТОС, а не суперцикл.

Да там всё неправильно - один мастер на всех, и тот совсем слабый...

[jcxz 218]

2 часа назад, syoma сказал:

Тогда задержка будет в идеале 0.0с и зависеть только от загрузки сети.

Не будет такого никогда. Так как CAN пока не работает на сверхсветовых скоростях. А так как у ТС линия ==2 км, значит нужно как минимум ~7мкс чтобы сигнал успел распространиться по линии. Это не считая ёмкости/индуктивности линии и задержек на мостах между сегментами (если такие есть). А для возможности работы механизма разрешения коллизий, нужно чтобы время распространения по всей линии (включая все межсегментные мосты) было многократно меньше длительности бита. И для того чтобы правильно выбрать точку сэмплирования бита CAN (о которой тут выше уже писали) так, чтобы в любом узле эта точка была правильной, и её положение не зависело от расстояния до передатчика - тоже нужно, чтобы длительность бита была многократно больше времени распространения сигнала по всей линии.

И тогда получаем для расстояния 2км максимальную скорость около 20кбит/с. А с репитерами - ещё меньше.

А у ТС сейчас RS-485 на 57600 кбод работает вроде как. И ему ещё мало. С CAN будет меньше.

2 часа назад, syoma сказал:

Механизм Ack в CAN гарантирует, что конкретное сообщение либо будет принято всеми активными узлами в сети, либо не будет принято ни одним из них.

Не гарантирует. ACK выставляется приёмником доминантным уровнем. А значит достаточно одному приёмнику его увидеть, он выставит доминанту, а какой-то из узлов может его не принять (из-за помехи за репитером в его сегменте) и пусть он сколько угодно выставляет рецессивный уровень - передатчик ACK всё равно получит.

1 час назад, Алексей Васильевич сказал:

Посылаешь 1000 запросов и получаешь один ответ через 30 секунд у лучшем случае

Значит ищите баги в своём коде.

[jcxz 218]

1 час назад, syoma сказал:

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

С чего это? Читаем описание CAN на википедии:

Контрольная сумма: передатчик вычисляет её и добавляет в передаваемый кадр, приёмник считает контрольную сумму принимаемого кадра в реальном времени (одновременно с передатчиком), сравнивает с суммой в самом кадре и в случае совпадения передаёт доминантный бит в промежутке подтверждения.

Т.е. - если КС не совпала - просто узел не выставит ACK (оставит рецессив). А более близкий узел, который не словил эту помеху - выставит доминантный ACK. А значит передатчик получит ACK.

"Активная ошибка" вообще для другого назначения используется.

[syoma 1]

29 minutes ago, jcxz said:

Не будет такого никогда.

Ну запишите 0.01с. Хватит?

Quote

Т.е. - если КС не совпала - просто узел не выставит ACK (оставит рецессив).

Это верно. Но для дальнейших действий может лучше почитаем CAN спецификацию?

Quote

6.2 Error Signalling

A station detecting an error condition signals this by transmitting an ERROR FLAG. For an ’error active’ node it is an ACTIVE ERROR FLAG, for an ’error passive’ node it is a PASSIVE ERROR FLAG. Whenever a BIT ERROR, a STUFF ERROR, a FORM ERROR or an ACKNOWLEDGMENT ERROR is detected by any station, transmission of an ERROR FLAG is started at the respective station at the next bit.Whenever a CRC ERROR is detected, transmission of an ERROR FLAG starts at the bit following the ACK DELIMITER, unless an ERROR FLAG for another condition has already been started.

Я тоже неправильно сказал - это не часть механизма ACK, а на один бит после него.

И чтобы потом не говорили, что после ACK сообщение считается принятым. Нет не считается:

Quote

Receivers:The message is valid for the receivers, if there is no error until the last but one bit of END OF FRAME

А ACTIVE ERROR FLAG после ACK этот END OF FRAME еффективно уничтожает.

[jcxz 218]

36 минут назад, HardEgor сказал:

Зачем одновременно? Есть адрес устройства ADDR , в самом простом случае, при одинаковом размере пакета Nbit,  вычисляйте задержку начала передачи каждого устройства:

(ADDR-1) + 1000*Nbit/speed, ms

Чтобы убрать влияние времени обработки пакета, я бы сделал немного по-другому:

1. Мастер отправляет всем кадры, которые нужно (до 1000-ти кадров). Ни один слэйв не отправляет ответ, а если хочет ответить, то просто формирует ответ в своём внутреннем буфере передачи (нозовём это кадром статуса).

2. После отправки последнего кадра, мастер отправляет спец. кадр запроса кадра статуса с нужного узла. Запрашиваемый узел сразу стартует передачу заранее подготовленного кадра статуса из буфера. "Сразу" - это означает: после приёма последнего стоп-бита последнего байта кадра запроса от мастера, слэйв запускает таймер задержки переключения ПРИЁМ-ПЕРЕДАЧА. За время этой задержки мастер и слэйв переключают свои драйверы линии, первый - из передачи в приём, второй - из приёма в передачу. После завершения задержки - слэйв передаёт кадр статуса.

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

[HardEgor 71]

1 час назад, jcxz сказал:

Чтобы убрать влияние времени обработки пакета, я бы сделал немного по-другому:

Схема понятна.

Автору его 1000 устройств надо бить на подсети  - на каждые 50 приборов ставить свой мастер и все проблемы сразу и безоговорочно уйдут.

[AlexandrY 3]

3 hours ago, syoma said:

Ну запишите 0.01с. Хватит?

Это верно. Но для дальнейших действий может лучше почитаем CAN спецификацию?

Эт конечно уместное замечание, про генерацию флагов ошибки на шине. 
Как-то я даже не обращал внимания раньше на такую фичу, больше заботили программные ошибки когда узлы не отвечают из-за своего софта.
Но создатели CAN видимо не брали в расчет ошибки софта считая что в их сети работают заведомо надежные дивайсы. 
С этой точки зрения, да, если дивайсы не протестированы на все 100%, то CAN как бы идеологически неверный выбор.  

С другой стороны как флаг ошибки передать через роутер в CAN-е? 
Тогда значит роутеры не получатся, а надо делать то что я назвал бы доменные контроллеры или coupler-ы как это называется у производителей PLC. 

Я б сразу делал EtherCAT.