FrSky Taranis - Максимум возможностей за минимальные деньги.
Правильнее наверное в микшере.
Немного про то как я использовал разные возможности.
Допустим у нас на канале две сервы, которые должны работать по-разному. В случае с микшером все делается без проблем, а в случае с инпутом как задать разный вес для разных каналов? Можно конечно и в outputs что-то настроить, но там настройки явно не для этого. Там удобно ограничивать ходы серв в соответствии с ходом скажем элерона: когда на 100% хода серва жужжит от того что не хватает хода петли или на качалке газа…
Я бы воздержался от слов “правильно/неправильно” по отношению к программированию аппы. Тут скорее все зависит от задачи и вариантов ее решения со своими плюсами и минусами.
Ибо как сказал мой друг, на вопрос “А почему через левое ухо?”, “Ну и что? Работает же!”. 😁
Кто еще целенаправленно использует разделение дублирования функций и как именно?
В Инпутах - полетные режимы(для каждого или для единственного - расходы и экспоненты) (в общем - основные настройки в каналах без их взаимного влияния), в Миксах - собственно миксы между каналами и т.п. (в общем - настройки, изменяющие один или группу каналов от других, временные и регулировочные настройки)
Я бы воздержался от слов “правильно/неправильно”
Вот и воздержись. 😃
Я написал: “правильнее наверное”. Это не утверждение, а предположение.
Алексей, я не в претензии, я внимаю каждому посту. Спасибо, что учавствуете в беседе.
Просто многие спрашивают: “а как правильно?”, что не всегда кмк корректно.
Как инженер-программист скажу так: правильнее так, что если понадобится что-то переделать, то тратилось минимум времени, не влияя на всю систему в целом.
Это как линейное программирование и ООП. Поэтому не все варианты правильные с точки зрения модернизации, а тот что описал я - правильный с многих точек зрения и не отрицает другие варианты.
А так по сути спор “ни о чем”. Таранис имеет столько настроек, что в конечном итоге дает тысячи разных комбинаций, но не все из них рациональны.
до миксов так и не дошел, все замикшеровал на импутах. На лицо явное дублирование функционала
Я тоже так сначала сделал, но потом один наш товарищ меня переубедил:
Не совсем один. Лучше все настраивать в микширах, т.к. инпуты имеют глобальное влияние на настройки, а микшира локальное. Если прощщще, то инпуты влияют на микшира, а микшира на инпуты нет. Потом могут быть непонятки в дальнейших настройках микширов.
и я все переделал.😃😃😃
Алексей, я не спорю, я ищу реальные примеры рационального использования двух настроек. Как привел пример Андрей выше, принцип мне понятен.
Расходы и экспоненты - в Input. Все остальное в микшерах.
Много сложных моделей с большим количеством плоскостей управления. С таким подходом меньше путаницы
Я тоже счел твои выкладки обоснованными и поэтому переделал. Это что-то типа глобальных и локальных переменных. А, самое главное, что оно все работает.😃
Расходы и экспоненты - в Input
Изменив это в инпутах оно будет таким везде.
Дело давно было, но примерно так.
В инпутах настроил экспоненты, расходы и что-то еще, возможно. И при полном отклонении стика внезапно происходила полная перекладка то ли элеронов, то ли элеватора. А может РН. Не помню. С тех пор настройками в инпутах пользуюсь весьма осторожно и ограниченно. Причем перекладка была именно в аппе, т.е. отображалась на экране. С чем было связано, вроде так и не разобрался. Или забыл. Экспериментировать неохота.
А поводу чем лучше пользоваться, мое имхо таково.
Что касается инпутов - настраивать через них характеристики взаимодействия оператора с пультом такие как мертвые зоны, экспонента для приведения зависимости отклонения стиков к изменению значения к комфортным значениям - если требуется. Причем скорее всего для одного и того же пользователя оно скорее всего будет примерно одинаковым для всех моделей. Выходные характеристики типа крайних точек серв и направления - в аутпутах/сервах. Различные взаимодействия управляющих каналов, расходы, режимы, экспоненты для разных режимов - в миксах, что мне кажется самым логичным.
На лицо явное дублирование функционала
Это не дублирование функционала, это гибкость системы. Если одного и того же функционала можно добиться разными способами, то более правильным будет тот который требует для этого меньше ресурсов.
меньше ресурсов.
Это не про Таранис.
Это не про Таранис.
Подробности!!!
Ведь “меньше ресурсов” может означать одну строку в логических переключателях, а не пять(!!!) для решения одной и той же задачи.
Это не про Таранис.
Причем тут Таранис, мы вродь про ОпенТХ счас.
Ведь “меньше ресурсов” может означать одну строку в логических переключателях, а не пять(!!!) для решения одной и той же задачи.
Так точно. Ровно как и в миксах.
Как инженер-программист скажу так: правильнее так, что если понадобится что-то переделать, то тратилось минимум времени, не влияя на всю систему в целом.
Это как линейное программирование и ООП.
Как прожженый админ скажу, работает, не трогай:-)
На самом деле сравнение хорошее. Тут чистое ООП привязанное к железу, и с весьма хорошим уровнем абстракции. Входы (импутсы) описывают поведение органов управления. Выходы (аутпутсы) описывают поведение исполнительных механизмов. Миксы мутят связи между первыми и вторыми.
давно было
меньше ресурсов
Вопрос поднимался неск лет назад. Тогда было полное непонимание и все забили. Я тоже забил.
Как инженер-программист скажу так: правильнее так, что если понадобится что-то переделать, то тратилось минимум времени
Как прожженый админ скажу, работает, не трогай
Админы - ленивые люди. С точки зрения админов справедливы оба тезиса.
Скажу как закостенелый хирург: аппендикс можно вырезать через ж…, через горло, распоров всю брюшину с выемкой всего содержимого. А можно через 2 прокола напрямую. Результат - один. Время и ресурсы разные.
Допустим таранис выполняет код за 50 условных единиц времени. Тот же, но правильный код он выполнит за 20 уе. Вроде хорошо, но какая разница, если общая задержка выполнения составляет 250 уе?
Ещё никто не сталкивался с тем, что Тарарису не хватает времени (тактов) на выполнение той или иной задачи, но куча народу имело проблемы в ситуации, когда ты слегка сдвинул один параметр, а все остальное уехало к чертям собачьим …
По этому я считаю, что стремиться к минимальному времени на задачу в данном контексте - ни о чем…
Вроде хорошо, но какая разница, если общая задержка выполнения составляет 250 уе?
Я не про те ресурсы.
Ведь “меньше ресурсов” может означать одну строку в логических переключателях, а не пять(!!!) для решения одной и той же задачи.
Я вот про эти.
Расходы и экспоненты - в Input. Все остальное в микшерах.
Я тоже сделал так.
В начале, расходы и экспоненты сделал в микшерах. При переключении на другие расходы, нуль уходил. Долго не мог понять, почему куда-то тянет. Потом на земле заметил, рули двигаются при переключениях. Не много, буквально десятые доли миллиметра, но уходят. Почему не знаю. Сделал все в Input и все стало хорошо.
Как прожженый админ скажу, работает, не трогай:-)
Имею абсолютно противоположную точку зрения в этой же сфере: надо постоянно трогать и обновлять.
Так сложность не будет накапливаться, чтобы в один момент не потребовать немыслимых ресурсов на поддержку или грандиозно развалиться.
Имею абсолютно противоположную точку зрения в этой же сфере
Пройдет:-)
ЗЫ Трогать и обновлять нужно только если в этом есть необходимость. Наличие новой версии необходимостью не является.