Хочется завязать мое приложение на Си (QT) и LabView. До этого делал связку через dll. А хочу использовать LabView как панель управления и индикации, типа как отладочное приложение. То есть приложение должно работать независимо от LabView, но LW должно иметь возможность к нему подключаться, чтобы получать данные из массивов, и передавать туда тоже некоторые данные. Я представляю это как вызов некого модуля, аналогичного вызову dll.
При помощи чего такое можно реализовать и где посмотреть пример ?
Независимая связь с приложением
-
- developer
- Сообщения: 257
- Зарегистрирован: 03 янв 2014, 19:37
- Версия LabVIEW: 2016
- Откуда: Украина, Киев
- Контактная информация:
Re: Независимая связь с приложением
ещё можно связать приложения через порт TCP, например. При этом портов можно использовать несколько - к примеру, по одному порту идёт общение запрос-ответ, а по другому - постоянный приём-передача данных.
колдооооовствооооо! (С)
-
IvanLis
- guru
- Сообщения: 5467
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 88 раз
Re: Независимая связь с приложением
Это наверное наиболее быстро реализуемый вариант. Только лучше использовать UDP, там без установки соединения. Получается - отправил и забыл, - не принял, ну и х..рен с ним. Т.е. не обязательно должны быть запущены клиент и сервер.AlexanderKonoval писал(а):ещё можно связать приложения через порт TCP, например
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
- VIP
- Сообщения: 1338
- Зарегистрирован: 03 фев 2010, 00:42
- Награды: 6
- Версия LabVIEW: 6.1 - 2024
- Откуда: Германия
- Благодарил (а): 1 раз
- Поблагодарили: 44 раза
- Контактная информация:
Re: Независимая связь с приложением
Один из самых простейших способов - использовать Network Variables.
Библиотеку и заголовочныее файлы можно стащить из CVI.
Вот вам ссылки
http://www.ni.com/white-paper/5484/en/
http://zone.ni.com/reference/en-XX/help ... variables/
http://www.ni.com/white-paper/7515/en/
Если сами не справитесь, могу набросать пример, но раньше выходных не получится.
Там кода всего-то двадцать строк максимум.
Библиотеку и заголовочныее файлы можно стащить из CVI.
Вот вам ссылки
http://www.ni.com/white-paper/5484/en/
http://zone.ni.com/reference/en-XX/help ... variables/
http://www.ni.com/white-paper/7515/en/
Если сами не справитесь, могу набросать пример, но раньше выходных не получится.
Там кода всего-то двадцать строк максимум.
-
- beginner
- Сообщения: 11
- Зарегистрирован: 11 янв 2011, 12:38
- Версия LabVIEW: 2009
- Контактная информация:
Re: Независимая связь с приложением
Про сетевое соединение в курсе. Думал есть способ сделать некоторую область памяти общедоступной для приложения и LW.
Ксатати про Network Variables надо будет почитать, возможно что они смогут мне помочь.
Ксатати про Network Variables надо будет почитать, возможно что они смогут мне помочь.
-
- VIP
- Сообщения: 1338
- Зарегистрирован: 03 фев 2010, 00:42
- Награды: 6
- Версия LabVIEW: 6.1 - 2024
- Откуда: Германия
- Благодарил (а): 1 раз
- Поблагодарили: 44 раза
- Контактная информация:
Re: Независимая связь с приложением
Так тоже можно, но там возни со стороны Лабвью будет больше. Кроме того, эту область памяти формально придётся защищать семафорами.digi писал(а):Про сетевое соединение в курсе. Думал есть способ сделать некоторую область памяти общедоступной для приложения и LW.
Смотрите на эту тему функции в msdn
CreateFileMapping
OpenFileMapping
MapViewOfFile
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Независимая связь с приложением
Поздновато, мягко говоря, отвечаю, но хотелось бы упомянуть про одну малоизвестную технологию для связи процессов - каналы (pipes). В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных. Каналы делятся на анонимные (anonymous pipes) и именованные (named pipes). Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого. Именованные каналы передают произвольные данные и могут работать через сеть. Иллюстрация работы каналов:
произвольное_имя_канала». Чуть более подробное описание есть на википедии, здесь или в поиске.
сервер:
клиент:
Ещё одна иллюстрация на двух консольных программах, взятых отсюда:
Видим, что вывод от сервера читается клиентом, оба приложения подключены к каналу TestPipe в реальном времени.
Что касается , то для него написана неофициальная библиотека и ряд VI OpenG Pipes. Скачать весь пакет можно здесь (*.ogp файл для установки через VIPM) или здесь (архив - набор , исходники библиотеки, примеры) (выбрать внизу "Download GNU tarball" для скачки архива). (upd: 2-я ссылка изменилась - см. конец сообщения). На основе примеров из архива я сделал простенькую пару клиент-сервер.
сервер: клиент: Как видно на картинке, данные прекрасно передаются от сервера к клиенту: Эти также работают и с консольными программами клиента/сервера из вышеприведённой ссылки. Единственное, что потребовалось, - выполнить преобразование строки из/в UTF-8, т.к. кириллица отображалась кракозябрами. Естественно, в exe вариантах также всё будет работать, а кто сомневается, может скомпилировать клиент и сервер в два экзешника и испытать.
Также отдельно хотелось бы сказать, что пример System Command (cmd.exe) Test.vi может работать с консолью на ввод-вывод и на ошибки. Это означает, что каналы можно использовать для работы со стандартными потоками stdin, stdout и stderr, то есть, возможна полноценная работа с любым консольным приложением в реальном времени: не только запуск, но и передача/получение информации от приложения.
Также в архиве есть исходник библиотеки ogpipes.dll с определениями функций PipeOpen, PipeRead и т.д., что позволяет подключить эту библиотеку в какое либо стороннее приложение, которое может взаимодействовать с через технологию каналов.
Заканчивая свой пост, привожу также ссылку на программу Pipelist, позволяющую посмотреть список открытых в системе каналов.
upd:
1. Старая ссылка на SourceForge больше не работает. Привожу вот такую: https://sourceforge.net/p/opengtoolkit/ ... nk/lvpipe/ Для скачки архива нажать "Download Snapshot".
2. Альтернативный набор для Win32 Pipes - LV Process (проект GOLPI). В некоторых случаях более стабилен в работе и более понятен для рядового пользователя.
Для работы с каналами используются стандартные функции Windows API CreateFile, CloseHandle, ReadFile, WriteFile, чтобы открывать и закрывать канал, выполнять чтение и запись. Имя канала на локальном компьютере выглядит так: «\\.\pipe\сервер:
Код: Выделить всё
hPipe = CreateNamedPipe("\\\\.\\pipe\\mypipe", ...);
while (ConnectNamedPipe(hPipe, 0))
{
while (ReadFile(hPipe, buf, ...))
{
ProcessData(hPipe);
}
DisconnectNamedPipe(hPipe);
}
CloseHandle(hPipe);
Код: Выделить всё
hPipe = CreateFile("\\\\.\\pipe\\mypipe", ...);
// Request some operation
WriteFile(hPipe, buf, sizeof(buf));
ReadFile(hPipe, readBuf, sizeof(readBuf));
CloseHandle(hPipe);
Что касается , то для него написана неофициальная библиотека и ряд VI OpenG Pipes. Скачать весь пакет можно здесь (*.ogp файл для установки через VIPM) или здесь (архив - набор , исходники библиотеки, примеры) (выбрать внизу "Download GNU tarball" для скачки архива). (upd: 2-я ссылка изменилась - см. конец сообщения). На основе примеров из архива я сделал простенькую пару клиент-сервер.
сервер: клиент: Как видно на картинке, данные прекрасно передаются от сервера к клиенту: Эти также работают и с консольными программами клиента/сервера из вышеприведённой ссылки. Единственное, что потребовалось, - выполнить преобразование строки из/в UTF-8, т.к. кириллица отображалась кракозябрами. Естественно, в exe вариантах также всё будет работать, а кто сомневается, может скомпилировать клиент и сервер в два экзешника и испытать.
Также отдельно хотелось бы сказать, что пример System Command (cmd.exe) Test.vi может работать с консолью на ввод-вывод и на ошибки. Это означает, что каналы можно использовать для работы со стандартными потоками stdin, stdout и stderr, то есть, возможна полноценная работа с любым консольным приложением в реальном времени: не только запуск, но и передача/получение информации от приложения.
Также в архиве есть исходник библиотеки ogpipes.dll с определениями функций PipeOpen, PipeRead и т.д., что позволяет подключить эту библиотеку в какое либо стороннее приложение, которое может взаимодействовать с через технологию каналов.
Заканчивая свой пост, привожу также ссылку на программу Pipelist, позволяющую посмотреть список открытых в системе каналов.
upd:
1. Старая ссылка на SourceForge больше не работает. Привожу вот такую: https://sourceforge.net/p/opengtoolkit/ ... nk/lvpipe/ Для скачки архива нажать "Download Snapshot".
2. Альтернативный набор для Win32 Pipes - LV Process (проект GOLPI). В некоторых случаях более стабилен в работе и более понятен для рядового пользователя.