FrSky Taranis - Максимум возможностей за минимальные деньги.
Ребят. Помогите настроить триггер.
Есть Thr + SF + SG.
Есть триггер L1 на SF + SG в положении B = True
Нужен триггер L2 чтоб был True, когда L1 - False и THR на нуле. Но при этом он не переключался в False до тех пор, пока не будет L1 в True
Это пока драфт.
Если правильно понял описание, то у меня вот так получилось:
Ну тогда обясню ответ развернуто.
Развернуто - не всегда значит понятно. 😉
Отличие конкретно в чем?
Ну тогда обясню ответ развернуто.
А давайте поговорим, о том какие преимущества дает раздельная настройка устройств ввода (стиков) и отдельно миксов. Я как бы ко всем обращаюсь.
Разработчики разделили настройки преследуя какую-то другую цель, нежили нас запутать где и что выставлять.
Какие мысли есть на этот счет, кроме “одно изменяет все, второе только что-то одно”???
Как пример.
В Инпутах удобно ставить мертвую зону стика. При этом изменения любых параметров в миксах, как то экспоненты, ДРы не увеличат эту зону не на грамм. Что удобно.
когда программил свой пульт, до миксов так и не дошел, все замикшеровал на импутах. На лицо явное дублирование функционала - кто как привык, тот так и делает. У меня сейчас уже нет желания переделывать все на микшеры
Вот именно для этого я и хочу поднять тему. Кто еще целенаправленно использует разделение дублирования функций и как именно?
Правильнее наверное в микшере.
Немного про то как я использовал разные возможности.
Допустим у нас на канале две сервы, которые должны работать по-разному. В случае с микшером все делается без проблем, а в случае с инпутом как задать разный вес для разных каналов? Можно конечно и в outputs что-то настроить, но там настройки явно не для этого. Там удобно ограничивать ходы серв в соответствии с ходом скажем элерона: когда на 100% хода серва жужжит от того что не хватает хода петли или на качалке газа…
Я бы воздержался от слов “правильно/неправильно” по отношению к программированию аппы. Тут скорее все зависит от задачи и вариантов ее решения со своими плюсами и минусами.
Ибо как сказал мой друг, на вопрос “А почему через левое ухо?”, “Ну и что? Работает же!”. 😁
Кто еще целенаправленно использует разделение дублирования функций и как именно?
В Инпутах - полетные режимы(для каждого или для единственного - расходы и экспоненты) (в общем - основные настройки в каналах без их взаимного влияния), в Миксах - собственно миксы между каналами и т.п. (в общем - настройки, изменяющие один или группу каналов от других, временные и регулировочные настройки)
Я бы воздержался от слов “правильно/неправильно”
Вот и воздержись. 😃
Я написал: “правильнее наверное”. Это не утверждение, а предположение.
Алексей, я не в претензии, я внимаю каждому посту. Спасибо, что учавствуете в беседе.
Просто многие спрашивают: “а как правильно?”, что не всегда кмк корректно.
Как инженер-программист скажу так: правильнее так, что если понадобится что-то переделать, то тратилось минимум времени, не влияя на всю систему в целом.
Это как линейное программирование и ООП. Поэтому не все варианты правильные с точки зрения модернизации, а тот что описал я - правильный с многих точек зрения и не отрицает другие варианты.
А так по сути спор “ни о чем”. Таранис имеет столько настроек, что в конечном итоге дает тысячи разных комбинаций, но не все из них рациональны.
до миксов так и не дошел, все замикшеровал на импутах. На лицо явное дублирование функционала
Я тоже так сначала сделал, но потом один наш товарищ меня переубедил:
Не совсем один. Лучше все настраивать в микширах, т.к. инпуты имеют глобальное влияние на настройки, а микшира локальное. Если прощщще, то инпуты влияют на микшира, а микшира на инпуты нет. Потом могут быть непонятки в дальнейших настройках микширов.
и я все переделал.😃😃😃
Алексей, я не спорю, я ищу реальные примеры рационального использования двух настроек. Как привел пример Андрей выше, принцип мне понятен.
Расходы и экспоненты - в Input. Все остальное в микшерах.
Много сложных моделей с большим количеством плоскостей управления. С таким подходом меньше путаницы
Я тоже счел твои выкладки обоснованными и поэтому переделал. Это что-то типа глобальных и локальных переменных. А, самое главное, что оно все работает.😃
Расходы и экспоненты - в Input
Изменив это в инпутах оно будет таким везде.
Дело давно было, но примерно так.
В инпутах настроил экспоненты, расходы и что-то еще, возможно. И при полном отклонении стика внезапно происходила полная перекладка то ли элеронов, то ли элеватора. А может РН. Не помню. С тех пор настройками в инпутах пользуюсь весьма осторожно и ограниченно. Причем перекладка была именно в аппе, т.е. отображалась на экране. С чем было связано, вроде так и не разобрался. Или забыл. Экспериментировать неохота.
А поводу чем лучше пользоваться, мое имхо таково.
Что касается инпутов - настраивать через них характеристики взаимодействия оператора с пультом такие как мертвые зоны, экспонента для приведения зависимости отклонения стиков к изменению значения к комфортным значениям - если требуется. Причем скорее всего для одного и того же пользователя оно скорее всего будет примерно одинаковым для всех моделей. Выходные характеристики типа крайних точек серв и направления - в аутпутах/сервах. Различные взаимодействия управляющих каналов, расходы, режимы, экспоненты для разных режимов - в миксах, что мне кажется самым логичным.
На лицо явное дублирование функционала
Это не дублирование функционала, это гибкость системы. Если одного и того же функционала можно добиться разными способами, то более правильным будет тот который требует для этого меньше ресурсов.
меньше ресурсов.
Это не про Таранис.
Это не про Таранис.
Подробности!!!
Ведь “меньше ресурсов” может означать одну строку в логических переключателях, а не пять(!!!) для решения одной и той же задачи.
Это не про Таранис.
Причем тут Таранис, мы вродь про ОпенТХ счас.
Ведь “меньше ресурсов” может означать одну строку в логических переключателях, а не пять(!!!) для решения одной и той же задачи.
Так точно. Ровно как и в миксах.
Как инженер-программист скажу так: правильнее так, что если понадобится что-то переделать, то тратилось минимум времени, не влияя на всю систему в целом.
Это как линейное программирование и ООП.
Как прожженый админ скажу, работает, не трогай:-)
На самом деле сравнение хорошее. Тут чистое ООП привязанное к железу, и с весьма хорошим уровнем абстракции. Входы (импутсы) описывают поведение органов управления. Выходы (аутпутсы) описывают поведение исполнительных механизмов. Миксы мутят связи между первыми и вторыми.