-
- Нет :) Потому что это не сканирование. Основной режим - настроить
так, что передаваться будут только изменения. Это очень сильно
разгрузит шину. Cкpипaч(151 знак., 03.04.2023 10:03)
- Идеологически протокол заточен на вообще любой вариант. Еще раз говорю - можно сделать так, что "неожидаемых" сообщений не будет. И даже без SDO. И это сразу в два раза экономнее по полосе чем Модбас. - Alt@ir(03.04.2023 13:24)
- И как всегда, в самый ответственный момент, когда все рушится и
надо срочно что-то делать, у всей этой десятки датчиков пойдут
изменения и они выстроятся в очередь, что бы доложить о своей
жизни. И как на зло самый полезный датчик окажется в хвосте
очереди. А там еще добавится то, что изменения будут появляться
быстро, те, кто уже что-то сказал, начнут опять лезть, тормозя
очередь, и вся система управления зависнет до полного физического
краха, когда что-то делать станет уже AlexBi(7 знак., 03.04.2023 10:45)
- Вы протокол CANOpen изучили бы сначала перед тем как позориться. Там эта ситуация предусмотрена. "опять лезть, тормозя очередь" в правильно спроектированной системе никто не будет. Но Русские разработчики не могут ни первое ни второе. Нет в РФ заказчиков на "правильно спроектированные" системы. На сбор данных с бензоколонок есть а на многокоординатные станки - нет. И еще на автоматизацию курятников есть. Поэтому автоматизаторы курятников недоумевают зачем вообще изобрели 3m(8 знак., 03.04.2023 16:38)
- В CANe есть возможность самый полезный датчик настроить так, что ему никто не помешает. - Alt@ir(03.04.2023 13:17)
- Очень вредная, к слову, функция. - Cкpипaч(03.04.2023 13:30)
- Я тоже предпочитаю Modbus, с его детерминированностью, но на
практике
забивают йухиспользуют системы передачи сообщений. Если на десять датчиков дать полосу в 10мбит, то работать - будет. - Cкpипaч(03.04.2023 12:06)
- Нет :) Потому что это не сканирование. Основной режим - настроить
так, что передаваться будут только изменения. Это очень сильно
разгрузит шину. Cкpипaч(151 знак., 03.04.2023 10:03)