Уважаемые кокпитостроители и разработчики сопутствующих модулей, интересно узнать какая судьба ождидает имеющиеся на сегодняшний день разработки в связи с намечающимся выходом FSX? Будут ли они работоспособны в новой версии сима или необходимо будет их подвергать доработке? И насколько последняя (доработка) будет существенна?

И по поводу:

Batman (27.09.2006 21:29):

А чем FSUIPC плох, чтобы от него отказываться? Зачем изобретать то что уже придумано? Я с его помощью вытаскивал бОльшую часть нужных переменных… ну а что не получалось (для ПТ) — напрямую с сима.

С уважением, Михаил.

[quote name=’azatov’ post=’469834′ date=’12.10.2006 00:06′]

Цитата

Согласен, судя по отзывам о демоверсии FSX, радикальных изменений сим не претерпит. А все красивости и прочие новинки, как мне кажется, можно рассматривать как дополнения.
С точки зрения кокпитостроения, сам движок (поправьте если я не по месту применяю это понятие), а следовательно и архитектура симулятора остались без изменения. Соответственно, можно сделать вывод, что принципы по чтеию и записи значений переменных останутся прежними и труды не пропадут даром. Разве только придется немножко поправить адреса, имена и т.п.

Теперь что касается роутера — а нельзя ли при его разработке предусмотреть т.н. «избыточное планирование» и сделать его в виде «Конструктора»? Другими словами, сделать его гибким инструментом , который позвалял бы кокпитостроителю самому выбирать (1) значение какой переменной (2) в каком порядке и (3) в какой порт записывать.

Выполнение пункта 1 (выбор переменной) осуществлять из модуля (программы и т.п.) обеспечивающей связь между симом и роутером (см. рис.)

 1.bmp (24,72К)

Количество загрузок:: 16 (P.S. Кстати, как вставить рисунок?:))

Не уверен, что до конца понятно я изложил свою мысль — подведу итог: смысл введения такого модуля (программы или т.п…) как раз и сделает роутер универсальным.
Во-первых, пользователь сам сможет выбрать на какой порт и какое железо ему вешать.
Во-вторых, в случае каких либо изменений (Например: новая версия сима) необходимо перепесать будет только модуль, аппаратная же часть остается без изменений.
В третьих, область применения кокпита не будет ограничиваться лишь MSFS. Останется только написать соответствующие модули для различных симуляторов.

Возможно это и утопия, но как мне кажется, вполне реализуемо. По крайней мере, в моих домашних разработках удалось универсализировать модуль извлечения данных из АБСУ ПТ.

С уважением, Михаил.

Цитата

Никогда не пользовался. По-моему самому легче сделать, чем платить такие деньги. Всё дешевле получается.

Цитата

Этого не знаю, может кто-то и сделает. На форуме есть только схемы управления этими приборами. Создайте тему, может кто-то и захочет взятся за вашу проблему. Но по-моему, легче вам самому научиться это делать. Обратитесь к Александру Данилину (ra3dsc), мне он помог с этой проблемой разобраться.

Cockpit Builder (8.10.2006 21:27):

Ребята, да не слово бесплатно испугало, за это время под моим руководством была разработана и введена в промышленную эксплуатацию автоматика очень серьезного объекта. Просто все вокруг кричат хочу универсальность, хочу что бы мой труд не канул в небытие, давайте вместе. И что ? Вот прошло 6 месяцев. И что ? Покажите хоть одну массовую деталь. Да, кто-то переделал радиовысотомер в указатель спуск-подьем. Круто. А кто-то таки сгенерировал 3 фазы. Еще круче. А есть еще хоть кто-то кто это повторил ? Да?! 2 человека ?! Крууууууто ! Задача решена — у каждого симуляторщика дома стоит железный указатель спуск-подьем, а сам прибор настолько универсален, что годится для любых целей, так ? Как нет ? Жалко. Зато как мы умеем похаить, как мы умеем обидеть !!! Какие мы все здесь собрались крутые !!! Смешно блин.

Evgeny_ (13.06.2007 21:43):

10 рахрядный ЦАП под FSBUS уже существует и работает. Вернее 12 разрядный, просто микросхема ЦАП применяется КР572ПА1. Может быть ваши знания направить в другое русло. Обратите внимание на веточку Требуется программист микроконтроллеров. Для поддержки проекта FSBUS.

601 (14.06.2007 00:03):

Вот ЦАП!!!!

Мы не сомневаемся в Вашем опыте и компетенции. Просто изначально Вы вопрос не до конца изучили — все просто как ясный день.
Для тех, кто хочет купить — давно есть решения из-за рубежа. Особенно по части кокпитов Боингов и Айрбасов. И им морочиться с Вашими промышленными контроллерами нет никакого желания.
Для тех, кто хочет сделать все сам — УЖЕ ВСЕ ЕСТЬ. И схемы, и софт и все бесплатное. Есть проблемы с отечественными «будильничными» приборами, но они решаются мал помалу, в зависимости от каждого отдельного прибора.
Поэтому все и спрашивают, зачем изобретать что-то, что уже есть, и вполне неплохо работает. По крайней мере для среднего домашнего кокпита западного самолета достаточно Mjoy, FSUIPC, FSBus, IOcards.
А разговоры про то, что собрал контроллер, но не знаю как нумеруются ноги микросхем, это, простите, демагогия. Люди, не разбирающиеся в электронике ничего строить не будут, не по существующим, не по Вашим будущим схемам.

Evgeny_ (14.06.2007 14:32):

Непосредственное согласование микросхемы КР572АП1 с цифровыми ТТЛ -микросхемами возможно при работе от источника питания 5 вольт. Однако электрические параметры ЦАП при этом ухудшаются, Поэтому рекомендуется для согласования выходов ТТЛ – микросхем и цифровых входов ЦАП включать между ними и шиной питания 5 В резисторы сопротивлением 2-10 кОм. Кстати первый вариант модуля не имел этих резисторов – все равно работает. Так что на всякий случай поставил.

azatov (14.06.2007 15:26):

Знаешь, когда контроллеры это не хобби для себя и не стремление узнать что-то новое, а ежедневная рутинная работа, когда зажечь лампочку по событию или вычислить каку-либо функцию на контроллере это не творческий процесс а типовое проверенное решение, энтузиазм сильно убавляется и начинается понимание, что конечный успех и время разработки на 90 процентов зависит от правильности и точности ТЗ и лишь на 10 от сложности конкретной задачи. И, невольно смотря на ТЗ на этом форуме именно с этой точки зрения, понимаешь, что даже выполнив его на 100% результата не будет потому, что изначальная задача кривая и неполная. Вот тебе пример: бегала тут проблема с компасом — что после 359 градусов он крутится на 0 через весь круг. Что в ТЗ ? Люди пытаются вынести это в вычислитель СИОК и передавать какие-то параметры типа направления, которых негде не предусмотрено. Изначально неверная задача. Задача должна стоять примерно так:
(1) Значения на входе прибора изменяются в диапазоне от 0 до 360 градусов.
(2) Значения могут меняться с любым шагом (проскакивание промежуточных значений), при этом прибор должен найти оптимальную сторону доворота указателя, т.е. значение может поменяться с 90 на 300 и прибор должен повернуть указатель через кратчайшую сторону.
(3) При включении прибор должен самостоятельно провести калибровку числа оборотов на единицу значения входа по датчику 0 градусов, а так же установить указатель на NW, для чего необходимо и достаточно выполнить поворот по часовой стрелке до срабатывания датчика 0 и затем еще один оборот до повторного срабатывания датчика 0.
(4) полученное калибровочное значение необходимо сохранить в энергонезависимой памяти и при последующем включении питания использовать это значение для работы без калибровки и поиска нуля.
(5) предусмотреть в контроллере вход или команду калибровки, по которой прибор инициирует процедуру 3 в любое время.
(6) На выходе прибор дает серию импульсов с положительной или отрицательной фазой сдвига (далее идут технические тонкости двигателя) причем для вращения по часовой стрелке сдвиг положительный.
(…)
(27) Прочие тонкости и пожелания в свободной форме (кто в теме знает, что без этого нет ни одного ТЗ 😉 однако этот пункт не считается обязательным для решения задачи)

Пример реализации пункта (2) — с чем на форуме имелись проблемы.
Предполагаем, что у нас есть функция avsim_step_go(X,Y), умеющая вращать шкив на Х градусов в сторону Y, причем при Y=1 поворот по часовой, и против в противном случае. Пишем функцию, на входе которой подается новое значение B и старое значение A (вторая переменная есть программная обратная связь с текущим положением штока, чтобы если прибор не отработал до конца поворот, запуск нового позиционирования не привел к сбою в расчете угла, т.е. переменная A всегда содержит реальную позицию штока, и, вероятно, для решения задачи 4 хранится в NVRAM). Пусть она называется avsim_rotate(A,B ) и возвращает на выходе значение 0 если все ОК, или иное, если присутствует какая-либо ошибка.
Теперь мыслим математически: Напишем условия, при которых вращение стрелки будет обратным. При несоблюдении ни одного из условий, считаем вращение положительным. На ум приходит два условия. 1) A>B; 0<A-B<180 2) A-B<(-180). Т.е. функция должна проверить два неравенства (первое из которых на самом деле система неравенств) и если любое из неравенств выполнилось, то Y=0 или Y=1 если ни одно из неравенств не выполнилось. Вроде так.
Теперь это воплощаем технически:
* int avsim_rotate(int A, int B )
* {
* if ((A>359)||(B>359)||(A<0)||(B<0)) return -1; // вызов функции нарушает регламент
* if ( (A>B)&&((A-B )>0)&&((A-B )<180) || ((A-B )<-180) Y=0; else Y=1; // вычисляем направление
* X=abs(A-B ); // количество градусов для поворота (модуль-дельта)
* res=avsim_step_go(X,Y); // крутим шкив на Х градусов в сторону Y
* if (res==0) return 0; // успешно завершено
* else return -2; // сбой аппаратной части — обычно вызывает аварийную программу, она у нас в ТЗ под пунктом 24, например поднимает красный блинкер — мы ведь не играться вышли, мы же прибор строим, который может заклинить или иметь программную ошибку, а у нас паксы за спиной 🙂
* }
Извини, если что не досмотрел, писал с лёту и без моделирования, но идея, наверное, верная. Чего столько эту проблему мусолить я не понимаю, особенно помню чей-то пост «в FSUPIC заявлено что эта проблема решена». Крутые они там в своем FSUPIC реально — 2 действия смогли вместе слабать. Ладно, это риторика.
Но посмотри. Вот, допустим, ты не знаешь или не хочешь знать контроллеры, но ты грамотный человек и понимаешь, что надо сделать с точки зрения вычисления, для того чтобы твой конкретный прибор заработал. А я не знаю сколько там у тебя сельсинов и какой коэффициент редукции, но знаю контроллер. Ты мне пишешь формулы, по которым надо тебе выдавать сдвиг фаз по какому-то входному значению, а я пишу тебе программу которая это делает. И ты и я не напрягаясь решили задачу. Но когда ты заставляешь (просьбой помочь) меня поднимать справочник по сельсинам, разбирать прибор, считать зубцы — это меня очень напрягает. И это нельзя назвать моим нежеланием помочь другим людям потому что это бесплатно. Просто я это не умею делать и мне на то чтобы разобраться потребуется куча времени и железо, которого у меня нет. Поэтому предлагаю свою реальную помощь в области, которую, думаю, неплохо знаю, в виде разработки программ по Вашему ТЗ на программу. Только ТЗ ставьте предельно конкретное. Еще могу помочь по цифровой схемотехнике. Аналоговую не знаю в степени, достаточной для проектирования (расчета) усилителей тока или напряжения — знаю только теорию из института. Вообще задачи такого типа решаются четырьмя людьми — ГИП (он же постановщик задачи), системотехник(разрабатывает схемную реализацию сопряжения), программер(ноу комментс), математик(формализует ТЗ для программера). Это классика. Когда один человек делает все это сразу — получается либо долго, либо хреново, либо вообще не работает. Программа минимум — ГИП-математик в одном лице и системотехник-программер в одном лице. Но будет скрипеть и может треснуть на реальных задачах. А далее — бывают задачи когда математическую часть делают 5-10 человек потому что очень много вычислений и приходится писать свои библиотеки. Но это мы отвлеклись.
Короче вот такое мое стороннее видение как сделать так, чтобы все получилось. А так как здесь, на данный момент, это ИМХО тупиковый вариант, что я прошлый раз и сказал, правда более кратко. Может что-то сдвинется после этого поста.