Вот если был бы ктонить был бы заинтересован в создании транслятора IP пакетов из ARCC в SIOC — цены проекту небыло бы.. Я бы занялся, но нужно знать аппаратный протокол IOcards чтобы притвариться IOcards…. А это они хранят в строгом секрете…

Ну мне, например, это интересно. Но только зачем притворятся IOCARDS? У Вас есть аппаратные модули и есть некий API, который может их опрашивать и выдавать в них данные. Надо написать IOCP клиент с вашим API, а протокол IOCP открыт и докуметирован. Я, например, использую тот код в части протокола IOCP, что в свое время выкладывал у себя на сайте Niko Kaan.
В концепции SIOCа — один контрол — всегда одна переменная. Когда с ней что-то происходит, когда она меняется при помощи любого события, выполняется скрипт, который с ней связан. Т.е. если написать IOCP сервер с простейшей логикой, т.е. связь, как, например, состояние переключателя <-> SIOC переменная, и наоборот, SIOC переменная <-> положение шаговика, или состояние лампы, вот это бы было то, что нужно.
Я, может, ретроград, но мое ИМХО, что лучше иметь прогу, которая быстро и точно работает, кушая конфиг из ini файла, чем наворачивать адский GUI на MFC. Мои проги простые донельзя. И мне так удобно. Вот такой драйвер + ваше отлаженное железо было бы здорово состыковать.
Ну и опять же по поводу коммерческой выгоды, мое имхо, что в таком деле как кокпитостроение с уровнем его распространения у нас выживут только фришные проекты. Получить заметную прибыль от таких систем на хоббийном рынке мне кажется нереально. А вот вариант как с мджоем или Opencockpits прокатит — хочешь собрать, собирай сам. Хочешь готовый заплати.

Между железом и TCP/IP работает в фоновом режиме некий сервис , которые переводит протокол железа в пакеты TCP/IP
…
Тоже самое в вашем случае — на сколько я понял — нужно модифицировать наш «драйвер» под протокол IOCP , коорый общается по TCP/IP с внешним миром так ? ..

Совершенно верно. Нужно чтобы ваш «драйвер» имел некую простейшую конфигурилку, которая бы ему сказала, какие аппаратные части нужно соответствовать киким номерам переменных SIOC (все переменные SIOC нумеруются от 0 до 9999). Далее при помощи протокола IOCP ваш «двайвер» сообщит SIOC серверу какие произошли изменения переменных на ввод по сообщениям от железа. И наоборот, SIOC сервер сообщит драйверу какие произошли изменения в переменных на вывод, чтобы драйвер передал сообщения в аппаратную часть. Список переменных за которыми нужно следить ваш «драйвер» объявляет SIOC серверу на этапе коннекта. Далее SIOC сервер будет отправлять вашему двайверу (который является для SIOC сервера IOCP клиентом) изменения касающиеся всех переменных, которые ваш драйвер SOIC серверу изначально объявил.
А задача синхронизации этих переменных с симом или еще с чем, это уже будет задача SIOC сервера и другого IOCP клиента, который связан уже с симом, которые уже написаны и для MSFS и для Xplane и для прямого доступа к памяти и вообще можно написать таких клиентов для Бог знает еще чего, хоть для жалюзей на окнах, которыми мы хотим дома через SIOC управлять.
Все отличие железа IOCARDS в том, что SIOC сервер имеет встроенную поддержку опроса контроллера аппаратной части IOCARDS. Но нам от этого не холодно и не жарко. Ну имеет и имеет, а мы будем поставлять ему данные от железа через IOCP протокол. Вся разница что мы будем писать в SIOC скрипте не линкуемые значения железа IOCARDS, как, например
Var 1002, Name Encoder1Change, Link IOCARD_ENCODER, Input 0, Aceleration 8, Type 1
А просто
Var 1002, Name Encoder1Change
и будем ждать информации о ней через IOCP протокол, предварительно сконфигурировав ваш драйвер привязав инкременты-декременты определенного энкодера к переменной номер 1002
Причем хочу обратить внимание на то, что даже переменная, объявленная как «Link IOCARD_ENCODER», она получает от железа в качестве свеого значения инкременты декременты, а обрабатывать их должна процедура, которая всегда вызвается при изменении переменной. Эта-же процедура и будет вызываться если SIOC сервер получит инкремент-декремент энкодера через IOCP протокол. Так что даже с точки зрения SIOC кода особо менять ничего не нужно будет.
А Вы, в свою очередь получите пользователей IOCARDS в числе потенциальных клиентов, если ваши железные модули проще удобнее и лучше.

МОжно ли увидеть этот протокол ? … Если есть такое — я посмотрю , можно ли чтонибудь придуматьи прикрутить ARCC к IOcards софту…

Описание протокола IOCP можно глянуть тут. Для удобства я его продублирую на случай изменения ссылки на Opencockpits.

The Protocol

IOCP is a protocol that can be improved in an easy way. What is not easy is to change all the clients and servers implementations. Manuel Vélez, Alberto Beaterio nor me are going to change it. What we do is expand it.

For the next notes, a character between ‘ ‘ means a character, and the value is the one indicated by the character. So ‘ ‘ means $20 or 32 or space.

NOTE: … (three dots) mean a non-determined numbers of characters (in a logic order) depending on the indicated thread.

0.- IOCP is a text, non codified protocol.

1.- IOCP was designed for UDP, and not TCP, but IOCPServer uses TCP. (see 12).

2.- It’s based in a client-server architecture where the clients must to be registered so the server knows what each client need. When something changes, the server informs the client (the client doesn’t need to ask for information).

3.- Variables are integer type. If decimals are required, the problem is soved by multiplying the data before sending it, and dividing when received by the client.

4.- Every IOCP message end with two characters: 13 and 10 ($0D and $0A), this is, the CR+LF sequence (CL in the rest of this document).

5.- Every IOCP registry start with the sequence «Arn.». The first four octects (bytes) of each registry are: ‘A’, ‘r’, ‘n’ and ‘.’

6.- The first message when the client connects to the server contains information about to whom the client has connected. The message is Arn.TipoSer:xxxxxx:CL where xxxxxxx is the server name.

i.e.: for IOCPServer, when a client connects, it gets the sequence:

where ‘n’ must be understand as the version of FS. IOCPServer 1.6 can send 7, 8 or 9 in this position for FS98, FS2000 or FS2004. For FSX it will send an A: «Arn.TipoSer:FSA:CL»

7.- Once the client knows its server, the client must be registered. starting the communication with the message: Arn.Inicio:var0:var1:…:varn:CL where var0, var1 to varn means the variables that the client is interested in.

8.- When client or server want to finish the connection, the one who wants to close will send the message «Arn.Fin:CL»

NOTE: If IOCPServer sends Arn.Fin:CL, the message is sent to every connected client. Server waits some time, not taking into account the «Arn.Fin:CL» messages sent when the clients close.

9.- (Only IOCPServer) IOCPServer understands and answers a special message: Arn.Preg that means the client wants to know the value of a variable that has not changed for a long time. So any client that connects to a server can ask for data even when the client is not registered. The format is: «Arn.Preg:var0:var1:…:varn:CL»

10.- After receiving a starting message, or a Arn.Preg message, or each time a registered variable changes, the server sends this message: «Arn.Resp:var0=val0:var1=val1:…:varn=valn:CL» where var0, var1, to varn represents the registered or asked variable number, and val0, val1 to valn, represents the value in the server.

11.- When a client wants to inform the server to change some variable value, the message will be the same as in the previous point: «Arn.Resp:var0=val0:var1=val1:…:varn=valn:CL» where var0, var1 to varn represents the variable number and val0, val1 to valn, represents the new values for the variables.
NOTE: IOCPServer answers with (in normal conditions) the same message received, so the client knows about the change. But if any value sent by the client is not valid or can’t be set in the simulator in that moment, the server answer will include the present variable value.
NOTE: Sometimes, the simulator accepts the new value, but after 150 ms., the variable is reset to the previous value. The server will inform the client about both changes with two different messages.

12.- IOCPServer does’t send «Arn.Vivo:CL». It answers with this message to a client, but the server doesn’t send it by itself. The clients state control is made via TCP.

13.- (Only IOCPServer) There is another message that can be answered by IOCPServer: «Arn.Key:nnn:CL» and means the request from a client to launch a FS event. This can’t be controlled by SIOC today, but i hope I will be able to do shortly. This way IOCPServer answers to the EVENT_QUIT event for example, this is, closes and ends the simulator without asking, just when receives this command. The values list can be located at IOCPServer website.

where nnnn, is an event to be launched, a key, or any other thing…

Ужас о чем люди пишут! Можно тока позавидовать…
Ладно, вопросик. vitabutch ты программил ПИК 16С745? Были траблы или нет? и чем программил?

Те С-шки, что у нас сейчас стоят, мы прошивали в представительстве Микрочипа в Киеве. Мне будет скоро нужна еще USB expantion, и буду программить Cшку скорее всего таким же простейшим JDM программатором по приципу внутрисхемного программирования. Но это будет не раньше чем через 2-3 недели и уже в Москве. Как я теперь понимаю, главное в программаторе — СТАБИЛЬНОСТЬ ПИТАНИЯ

Автор этой темы говорил, что он одноразовый…

Автор темы, как раз, многоразовый, а вот 16С745 — нет

Кстати, у нас есть TCP/IP транслятор пакетов из ARCC в комп и на оборот. Никаких ком портов. Все давно уже овер IP с открытым протоколом — сиди програми свое приложение на отлаженном железе… Вот если был бы ктонить был бы заинтересован в создании транслятора IP пакетов из ARCC в SIOC — цены проекту небыло бы.. Я бы занялся, но нужно знать аппаратный протокол IOcards чтобы притвариться IOcards…. А это они хранят в строгом секрете…

Мне это интересно. Но мне кажется Вы лукавите. Ваш транслятор — это (сугубо мое мнение) просто реализация переходника СОМ-Овер-ТСР. Думаю я так потому, что при самостоятельной реализации стека ТСР проблемы с транспортом из АРСС в СИОК быть не должно. Ведь протокол СИОК полностью открыт, а Ваша система так же событийная как и СИОК, т.е. формировать пакетик ТСР при тыкании кнопочки — это технически тривиальная задача. Кстати, от ТСР я бы отказался в пользу ЮДП (меньше ресурсов, проще обработка, свободный тайминг) — имею очень большой опыт в реализации связи по ИП-сетям для промышленных контроллеров.

http://dicom-msk.su/show.php?id=21220&title=EC11EBB24C03%20ALPS%20Electric ценник кусаецо….

Неправда. Самый дешевый механический энкодер (который лучше после покупки выкинуть сразу в помойку) стоит в максимуме до 150ти рублей. А в Альпс качество и сразу ДВА энкодера за 10 долларов.

Господа, поповоду шумов энкодров PEC серии — они действительно шумят и не кисло ! … Никакие 4-х фазные алгоритмы не справятся с таким шумом.. Причина шума — загрязнение контактов смазкой которую льют в роторо энкодера.!
решение проблемы —
РАЗБИРАЕМ ЭНКОДР И АЦЕТОНОМ МОЕТ АМИ КОНТАКТЫ КАК В САМОМ ЭНКОДЕРЕ так и сами контакты на якоре…
ВСЕ! После этого дешевый PEC превращаеться в ALPS..
Проверено десяток раз !

Спасибо за совет — я попробую дома. НО! На самом деле там еще и детенды невыразительные по сравнению с ALPS. Это тоже играет немаловажную роль в шуме.

Транслятор писал я, сделан он, как сервис видовс, слушает ком порт и, по приходу пакетов, вещает в сеть, по протоколу UDP.
Трансляция из ARCCPRO в SIOC элементарная штука — может сделать каждый, мне просто не до этого сейчас, да и особого смысла в этом не вижу.

Молодца