Argon (24.10.2021 09:27, просмотров: 7401)-
- Полуркай здесь у тебя немного другое и не надо так наворачивать, но
почитать полезно будет RxTx(1 знак., 25.10.2021 13:58, ссылка)
- ну очень спорная статейка... особенно когда афтар ссылается canbus - Aleksey_75(25.10.2021 14:08)
- Хочу напомнить can гарантирует доставку сообщения но не гарантирует
время доставки! Синхронизацию нужно слать с самым высоким
приоритетом id , а именно 0x000. По остальному не вижу никаких
проблем! - Aleksey_75(24.10.2021 10:14)
- да, спасибо, вроде помню немного об этом - Argon(24.10.2021 10:49)
- За 100 мс внутренние часы уйдут настолько критично? Да банальный
электрический счетчик уходит не более 1 с за сутки. - vllv2(24.10.2021 09:57,
)
- ну я это примерно, с огромным запасом ) - Argon(24.10.2021 10:09)
- Зачем так сложно? Почему бы не обязать арбитра выдавать в линию
сигналы точного времени не реже, чем NNN? Собственно, на этом всё. - SciFi(24.10.2021 09:37)
- т.е. разделение по времени - лишнее? - Argon(24.10.2021 09:43)
- Лучше расскажите, что делаете. Слово "синхронизация" можно
по-разному понимать. Все как партизаны, молчат как рыба об лёд... - SciFi(24.10.2021 09:44)
- Грубо - есть 2 сервопривода, к-рые надо включать одновременно по
команде с шины CAN. Т.е. есть платки-шагогенераторы с CAN
интерфейсом. Там не настолько требуется полный реалтайм, как в ЧПУ
оборудовании, тем не менее лаг в 0.5с будет фатален. Также при
аварии одного из сервоприводов нужно максимально быстро тормознуть
второй. Но это, вообще-то, не совсем про синхронизацию. - Argon(24.10.2021 10:08)
- Если придет просто тупо две команды одна за другой, то быстрее чем
задержка протокола сделать не получится. Если есть желание
заморочиться и сначала синхронизировать часы протоколом
синхронизации времени (а пускать точно в назначенное время) то это
немного другое. - RxTx(25.10.2021 14:01)
- "Другое" и имею ввиду, две команды одна за другой - слишком тупо.
Можно ведь команду отправить двум абонентам одним сообщением. - Argon(25.10.2021 14:25)
- А ты это делаешь ради искусства :) или реально посчитал сколько
задержка между двумя командами по CAN'у. Шина у тебя незанята или
по ней mp3 кто-то играет? :) - RxTx(25.10.2021 14:48)
- Заболевание перфекционизмом привело к склонности к необоснованному усложнению. - Argon(25.10.2021 15:14)
- можно! но я бы так делать не стал... проще назначить свой id
каждому узлу и не придется разгребать на программном уровне
сообщения - Aleksey_75(25.10.2021 14:28)
- Тогда отдельными сообщениями, но с синхронизацией. А надеяться на
минимальный лаг протокола как-то не хочется (хотя оно вроде и
должно работать). - Argon(25.10.2021 14:31)
- есть "псевдо мастер" который шлет сихру по id 0x000, её принимают все узлы! Дальше самые "серьезные приводы" id 0x001.... все остальное 0x700.... (кстати это адреса авто диагностики) Aleksey_75(55 знак., 25.10.2021 14:35)
- А нельзя ли принимать сообщения по маске ID? Т.е. два девайса с
разными ID, но совместимы по маске. И таки одним сообщением кидать
команду. - Argon(25.10.2021 14:33)
- нет проблем, можно... но каждый узел в любом случае будет на уровне
ПО разгребать "это мне или нет", 64 мкс сильно критично ? - Aleksey_75(25.10.2021 14:37)
- Я имел ввиду аппаратную селекцию по маске. Т.е. девайсу по идее не придется программно разгребать. Нет ли такой возможности в CAN? - Argon(25.10.2021 14:43)
- Наверное нет, но почему-то хотелось бы максимальной тишины на шине. - Argon(25.10.2021 14:40)
- дык в чем проблем ? я так понял вам в первую очередь интересна синхра, ну а команды они и есть команды "скока" будете двигать приводы так и будет занята шина... Aleksey_75(109 знак., 25.10.2021 14:46)
- нет проблем, можно... но каждый узел в любом случае будет на уровне
ПО разгребать "это мне или нет", 64 мкс сильно критично ? - Aleksey_75(25.10.2021 14:37)
- Тогда отдельными сообщениями, но с синхронизацией. А надеяться на
минимальный лаг протокола как-то не хочется (хотя оно вроде и
должно работать). - Argon(25.10.2021 14:31)
- А ты это делаешь ради искусства :) или реально посчитал сколько
задержка между двумя командами по CAN'у. Шина у тебя незанята или
по ней mp3 кто-то играет? :) - RxTx(25.10.2021 14:48)
- касаемо can 500К это будет 64 микросекунды, ни один привод такой таймаут даже не заметит.. главное правильно организовать распределение id каждому узлу - Aleksey_75(25.10.2021 14:13)
- "Другое" и имею ввиду, две команды одна за другой - слишком тупо.
Можно ведь команду отправить двум абонентам одним сообщением. - Argon(25.10.2021 14:25)
- Или еще: есть 2 независимых электронагревателя, управляемых низкочастотным ШИМом. Текущая общая потребляемая мощность не должна превышать некоторую величину. Пока еще не придумал как их между собой увязать, но без синхронизации явно никак. - Argon(24.10.2021 10:11)
- Если придет просто тупо две команды одна за другой, то быстрее чем
задержка протокола сделать не получится. Если есть желание
заморочиться и сначала синхронизировать часы протоколом
синхронизации времени (а пускать точно в назначенное время) то это
немного другое. - RxTx(25.10.2021 14:01)
- Грубо - есть 2 сервопривода, к-рые надо включать одновременно по
команде с шины CAN. Т.е. есть платки-шагогенераторы с CAN
интерфейсом. Там не настолько требуется полный реалтайм, как в ЧПУ
оборудовании, тем не менее лаг в 0.5с будет фатален. Также при
аварии одного из сервоприводов нужно максимально быстро тормознуть
второй. Но это, вообще-то, не совсем про синхронизацию. - Argon(24.10.2021 10:08)
- Лучше расскажите, что делаете. Слово "синхронизация" можно
по-разному понимать. Все как партизаны, молчат как рыба об лёд... - SciFi(24.10.2021 09:44)
- Главное поставить этим пакетам наивысший приоритет - lloyd(24.10.2021 09:39)
- ага - Argon(24.10.2021 10:49)
- т.е. разделение по времени - лишнее? - Argon(24.10.2021 09:43)
- Современные CAN-контроллеры умеют таймстампить время фактического приёма/передачи пакета. - lloyd(24.10.2021 09:35)
- Полуркай здесь у тебя немного другое и не надо так наворачивать, но
почитать полезно будет RxTx(1 знак., 25.10.2021 13:58, ссылка)