basilmak (17.12.2016 11:40, просмотров: 294) ответил Evgeny_CD на Высоконадежный протокол поверх UART. Частично основано на идеях fk0.-
- Але, мы тут святой грааль ищем. Данные + питание по одной паре. Вот с чем не будут спорить - так это чтобы подумать и минимизировать трафик и большие ошибки системы ("нога попала в колесо") даже при падении связи. - Evgeny_CD(17.12.2016 17:19)
- Гы! 8) (извините) Уважаемый Евгений вернулся на грешную землю :) Скрипач(550 знак., 17.12.2016 17:31)
- Честно - я всегда считал и считаю, что на срань мелких контроллеров должен приходиться один (или несколько - резерв) Host, который как управляет сетью, так и принивает все важные решения. Evgeny_CD(297 знак., 17.12.2016 17:41, ссылка)
- Никогда так не делал и, надеюсь, делать не стану. Ближайший пример - насосные скважины, работающие на огромный резервуар. От скважин до резервуара - до километра. Скрипач(636 знак., 17.12.2016 17:48 - 18.12.2016 11:01)
- Именно для верифицируемости опесорцный C++ PLC и нужен -> ЧТобы был готовый публично доступный фремворк, в котором ты поднимаешь модель связи, модели всех "PLC" с реальной программой, модели объектов управления и доказываешь, что все это отвечает Evgeny_CD(129 знак., 17.12.2016 18:01, ссылка)
- Безусловно, локальный контур управления насосом должен иметь устойчивый алгтритм работы. Устойчивый ко всему. Evgeny_CD(153 знак., 17.12.2016 17:55)
- Кстати, есть еще интересный случай, когда насосы работают не на наполнение резервуара, а на откачку того что что стекается в резервуар. В этом случае не так очевидно, что делать конкретному насосу при обрыве связи - если остановиться - все может AlexG(95 знак., 18.12.2016 07:09)
- Нет даже намёка на сомнение. Скрипач(466 знак., 18.12.2016 10:58 - 11:06)
- Проектировщиков подобных систем приковать цепью к насосу! ;) - VLLV(18.12.2016 07:57)
- Это не гуманно - очень часто насосы погружные - AlexG(18.12.2016 09:07)
Не себя в театре нужно любить, а театр в себеДо какой степени "умный" контроллер нужен на той или иной установке, определяется сложностью алгоритма удержания ее в области не-аварийного функционирования. Скрипач(424 знак., 17.12.2016 18:01)- СОгласился. Пусть будет координационный контроллер только для целей связи. Задает тайм-фреймы и динамически (по запросу) делит отавшуюся полосу. Evgeny_CD(59 знак., 17.12.2016 18:11)
- Точнее, пусть один их контроллеров на шине возьмет на себя такую фукнцию. - Evgeny_CD(17.12.2016 18:11)
- Крахоборство до добра не доводит. Преждевременная оптимизация - тоже. - Скрипач(18.12.2016 12:44)
- Точнее, пусть один их контроллеров на шине возьмет на себя такую фукнцию. - Evgeny_CD(17.12.2016 18:11)
- СОгласился. Пусть будет координационный контроллер только для целей связи. Задает тайм-фреймы и динамически (по запросу) делит отавшуюся полосу. Evgeny_CD(59 знак., 17.12.2016 18:11)
- Имено поэтому TDMA в каналах связи для таких целей рулит. - Evgeny_CD(17.12.2016 17:56)
- Кстати, есть еще интересный случай, когда насосы работают не на наполнение резервуара, а на откачку того что что стекается в резервуар. В этом случае не так очевидно, что делать конкретному насосу при обрыве связи - если остановиться - все может AlexG(95 знак., 18.12.2016 07:09)
- Никогда так не делал и, надеюсь, делать не стану. Ближайший пример - насосные скважины, работающие на огромный резервуар. От скважин до резервуара - до километра. Скрипач(636 знак., 17.12.2016 17:48 - 18.12.2016 11:01)
- Честно - я всегда считал и считаю, что на срань мелких контроллеров должен приходиться один (или несколько - резерв) Host, который как управляет сетью, так и принивает все важные решения. Evgeny_CD(297 знак., 17.12.2016 17:41, ссылка)
- Гы! 8) (извините) Уважаемый Евгений вернулся на грешную землю :) Скрипач(550 знак., 17.12.2016 17:31)
- Але, мы тут святой грааль ищем. Данные + питание по одной паре. Вот с чем не будут спорить - так это чтобы подумать и минимизировать трафик и большие ошибки системы ("нога попала в колесо") даже при падении связи. - Evgeny_CD(17.12.2016 17:19)