Вобщем, возникла необходимость сделать библиотеку LTR под Линукс.
Делаю на основе исходников ltrserver - но сама бибилотека будет на основе lcomp (так же под Линукс) - то есть, без сервера, а напрямую через сокеты.
Но в исходниках ltrserver есть не все. Как минимум нет заголовочного файла:
"//LTR//include//ltrapi_ll.h"
(нет определения значения LTR_IP_CTRL_PORT - хотя экспериментальным путем обнаружил, что это значение равно 21 ;-))
Можно ли получить недостающие файлы исходников? Мало ли, вдруг там еще какие важные константы есть, до которых еще не дошел. :-)

Насчет экспериментального значения ошибся. :-(

Интересно, каким образом Вы нашли порт 21 (вообще-то это ftp).
LTR_IP_CTRL_PORT = 11113.

Естественно, файл пропущен по ошибке. Смею надеяться, что это единственный случай, просто предполагалось, что эта библиотека будет исключена и интегрирована в прорамму ltrserver (она больше нигде не используется), и возникла путаница.

Заберите последнюю версию с http://www.lcard.ru/download/ltrserver1530_src.zip, пока не выложен полный комплект ltrserver+ltrapi. Там этот файл есть в src/ltrserver1530/api2

Александр Е:
Как, как... Стал тупо перебирать все порты и пробовать подключиться - вот 21-ый и подключился. Сперва подумал, что именно через ftp все и делается. А так как медленно перебирается, других (реальных) не дождался. И именно функционирование не проверял, потом уже понял, что ошибся.
Спасибо, буду делать дальше. Постараюсь сделать все по аналогии с lcomp (линуксовым), чтобы интерфес пользователя был унифицирован, а все частности уже на уровне библиотеки.

Крейт-контроллер не должен слушать 21й порт
Это Вы, наверное, на компьютере нашли. Ну да ладно.

Алексей, Вы взялись за грандиозную и нужную задачу. Если дело пойдет, я думаю, что будет иметь смысл как-то взаимовыгодно скооперироваться.

см. также
http://www.lcard.ru/forumthreads/8542

Сейчас я пока просто переношу код сервера на Линукс. А там еще буду думать, как сделать лучше - именно в виде сервера, как и под Windows, или все же в виде библиотеки типа lcomp. Второе предпочтительнее.
Пока переносится без проблем - все вызовы типа WSAxxx эмулирую через Линуксовые функции - по крайней мере, уже коннектится, команды отсылаются, ответы приходят. Завтра уже в планах запускать процесс данных, но вроде там все нормально - ничего специфического нет.
Но, разумеется, пока буду делать только для IP, а USB переносить не буду.

Александр Е
"Крейт-контроллер не должен слушать 21й порт
Это Вы, наверное, на компьютере нашли. Ну да ладно."
Да вроде в connect указывал именно адрес крейта - 192.168.2.100, а компьютер имеет адрес 192.168.2.1. :-)

В потоке данных есть специфическое, прежде всего мультиплексирование между многими модулями и многими клиентами, а также некоторые особые случаи - это фунцкии TCrate::PrepareDataForCrate() и TCrate::ParseDataFromCrate().

Есть пусть упрощения: если к одному крейту одновременно может подсоединяться только одно приложение, то понятие "клиент" исчезает, и отдельная программа-сервер не нужна, но все равно надо мультиплексировать модули (приложение должно иметь возможность, скажем, читать два разных АЦП и писать в ЦАП в произвольном порядке, внутри одного крейта).
То есть для приложения имеем потоки чтения и записи по каждому модулю (слоту), а для крейта - общие на крейт.

Ну и на верхнем уровне есть еще команды самих модулей, т.е. потом придется также реализовывать функциональность ltr11api, ltr212api и т.д. (это как раз просто, надстройка поверх ltrapi).

Спасибо за информацию!
Специфика нашей задачи - один клиент на крейт, причем даже один клиент, использующий все модули в крейте - в чем-то это проще. Поэтому и планируется сделать все в виде аналога lcomp.
Все - код сервера откомпилился и запустился. Следующая задача - разобраться, как цепляются клиенты, что посылают для конфигурирования АЦП и для начала сбора данных - и сделать все в виде одного фиксированного клиента.

Что, спортировали все, кроме GUI, вместе с потоками, арбитражом и event//'ами? Неслабо.

Что посылают - это смотрите исходники ltrXXXapi. Эти библиотеки опираются на LTR_Recv() и LTR_Send(), т.е. работают с демультиплексированным потоком отдельного модуля и реализуют уже специфичный для типа модуля протокол.
Их как раз портировать должно быть очень просто, особенно если в пределах 32bit little-endian - думаю, соберется практически без изменений, разве что где-нибудь пара winapi вызовов.

P.S. А кстати, любопытства ради, Вы не пробовали запускать ltrserver под wine?

Да - без интерфейса и клиентского модуля.
Сейчас как раз изучаю ltr11api и клиентский модуль, чтобы убрать блок взаимодействия с сервером и чтобы ltr11api напрямую к крейту обращался.
А так "сервер" запускается, только ждет поступающих команд - вот и проверю скоро уже, насколько все правильно в нем работает.
А под wine запускать не охота - нести лишнюю приблуду, которая не прибавит скорости.
Но, разумеется, если все же с переносом будет затык, придется искать другие пути. Но, надеюсь, затыка не будет - чуток совсем осталось. :-)

Много уважения программисту, который сервер писал. Сильная штука - по возможностям и реализации.
А дело близится к победному финалу - правда, пришлось много чего выкинуть, к примеру, все управляющие команды. Они вроде как и не нужны, когда клиент один.
Но прежде чем выкинуть, сперва уже под Виндами перегнал все под VC++, собрал вместе сервер и ltrapi и внимательно разобрался, что и как работает (как должно работать) - что нужно, а что - нет.
А зачем нужна команда LTR_GetCrateRawData?
В доках ее не нашел. Вроде как понятно, что она делает, но знать бы поточнее - она реализована через управляющие команды, вот и думаю, переносить или нет.

Спасибо У сервера долгая история, и руку приложило несколько человек. Стараемся по мере сил.

Управляющие команды - имеется в виду подключение/отключение IP крейтов и т.д. (канал CC_CONTROL)? Он не зависит от числа клиентов - просто команды либо нужны, либо нет. Получить список модулей или подключить крейт по IP может понадобиться и одному клиенту.
Просто, видимо, в библиотеке, линкуемой прямо к приложению, надо весь CC_CONTROL переделать в набор функций библиотеки. Т.е. телом функции LTR_ConnectIPCrate() будет не посылка команды серверу, а содержательная часть case CONTROL_COMMAND_IP_CONNECT из ltrclient.cpp.

Мы одинаково мыслим?

По идее, если клиент один, убирается две вещи. Во-первых, естественно, потоки и сокеты клиентов (ltrclient.cpp), ltrserviceclients.cpp и необходимость синхронизации между клиентами (но не между клиентом и крейтом). ClientGet() и ClientPut() от модуля можно прямо отдавать на верхний уровень. Как-то надо выбирать модули. Например, добавить функцию выбора канала и запоминать глобально, или же прямо в LTR_Recv() и LTR_Send() внести номер слота как параметр.

Во-вторых, есть экзотическая фича, чтобы к одному модулю могло подключиться несколько клиентов, и данные отдавались каждому. Именно поэтому буфер принятых данных сделан не обычный кольцевой, а странный TCrateModule::bufrec_t с запоминанием, сколько кто забрал слов. Если клиент один, то можно это упростить при желании.

LTR_GetCrateRawData() не нужна. Говорят, когда-то кому-то понадобилась для экзотических целей. Отдает поток чтения с крейта, не разобранный по модулям (копируется в виртуальный "слот 17").
Смело выкидывайте все, что отосится к MODULE_INDEX_RAW и ReadRawData.

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

А вот вопрос:
Число каналов 16, LTR_Recv запрашивает блок длиной 256 - столько и получает.
Но LTR11_ProcessData возвращает уже блок длиной 240 и ошибку LTR11_ERR_ADCDATA_CHNUM.
Понятно, что произошел какой-то сбой - данные "сдвинулись". Как можно вернуть все в нормальный режим работы? Может необработанный "хвост" как-то сдвинуть и обработать еще раз?

Все - вроде разобрался и работает.