Как добавить простой API в мое приложение C++ для доступа LabView?
У меня есть программа сбора данных, написанная на C++ (Visual Studio 6.0). Некоторые клиенты хотели бы управлять программным обеспечением из собственного программного обеспечения или LabView. Я хотел бы придумать простой API с dll, который я могу распространять для них, и хотел бы получить несколько советов о том, как начать работу. Это будет очень простой, может быть, 4 или 5 команд. Моя программа DAQ все еще будет работать в своем собственном окне на той же машине, я просто хотел бы настроить ее для управления с другого программа.
6 ответов
вы находитесь на правильном пути с DLL. Настоящий трюк, похоже, будет решать, какую межпроцессную связь (IPC) вы хотите использовать. Параметры: сокеты, каналы, общая память, объекты синхронизации (события и т. д.), файлов, реестра и т. д.
Как только вы решите это, затем реализуйте прослушиватель в исполняемом файле, чтобы ждать входящих сообщений IPC от любого программного обеспечения, использующего вашу DLL.
Что касается API, вы можете сохранить его просто, как ты и хотел. Попросите DLL предоставить ваши 4 или 5 функций (убедитесь, что вы используете только собственные типы данных, такие как char* и long, чтобы избежать проблем с границей модуля), а затем они будут использовать ваш механизм IPC для связи с вашим исполняющим приложением.
вещи, которые начинаются просто, как это имеет привычку расти с течением времени, так что вы можете быть лучше делать немного больше работы вперед и использовать технику, которая будет расти с вами.
реализация com-интерфейса для вашей программы даст клиентам много свободы в том, как интерфейс с ним, и вам не придется беспокоиться о механике IPC и т. д., Поскольку COM предназначен для того, чтобы скрыть все это от вас.
в будущем COM уже имеет хорошо определить идиомы для таких вещей, как события, которые хорошо поддерживаются языками сценариев и т. д., Если они вам понадобятся.
обновление: существует множество способов реализации COM. Вы можете построить его от первых принципалов с руководством хорошей книги COM, или пользой рамок как ATL для того чтобы сохранить некоторую из плиты боилера. Есть много хороших образцов, например, см. MSDN.
большим преимуществом COM является то, что вам не нужна DLL! Вы говорите, что ваше приложение всегда будет работать. Это означает, что он может выступать в качестве создателя COM-объекта ("локальный сервер").
Если кто-то захочет "stdcall" DLL вместо этого вы можете дать им DLL, которая внутренне просто перенаправляет все вызовы на COM-интерфейс. Написать его было бы тривиально. Вы говорите, что у вас есть только 5 функций. Это предполагает, что у вас есть один COM-интерфейс с этими 5 методами. Когда DLL-оболочка загружается, он просит ваш EXE создать свой COM-объект. DLL, в свою очередь, предоставляет 5 методов stdcall, каждый из которых вызывает один метод на COM-объекте.
вы может используйте dll. Я подумаю над этим. Но я бы также рассмотрел возможность создания простого API на основе http, предпочтительно RESTful.
преимущества: легко портировать. Можно написать клиентское приложение с любого языка тривиально. Может работать по сети. Тестирование становится проще (используйте язык сценариев или браузер).
недостатки: производительность будет медленнее. Значительно больше сантехники, чтобы настроить его на C++. Я не уверен, что LabView может сделать http звонки.
что-то типа:
http://xxx/data [получить, возможно, сообщение для тестирования]
http://xxx/data/start [пост]
http://xxx/data/stop [пост]
http://xxx/data/parameters [пост]
учитывая ваши требования к мая быть немного излишним, но тогда, возможно, нет. Многие приложения я работаю на пришлось быть портированным и было бы быстрее расширяться, если бы мы могли использовать более быстрый язык разработки для его тестирования и расширения.
LabVIEW поддерживает выполнение вызовов DLL, но это одно из слабых мест в разработке LabVIEW. Сделано неправильно, это может привести к приложению, которое более подвержено сбоям. Как разработчик LabVIEW, мне нравится предложение Мэттита о создании Службы HTTP. Каждый язык на каждой платформе, которая может сделать порт TCP / IP, может получить к нему доступ. Я думаю, вы можете использовать свой собственный протокол TCP/IP вместо полнопроходного HTTP, но в любом случае проблема совместимости решена.
Если вы используете DLL, вот несколько советов. Не используйте структуры или указатели на структуры в списке аргументов вызова функции. Не выделяйте память в DLL для передачи обратно в LabVIEW. LabVIEW встроен в управление memmory и не будет хорошо играть с другими. Это может относиться и к другим языкам с управлением памятью, таким как Java. LabVIEW будет работать лучше, если он выделяет память и передает указатель на DLL. Избегайте указателей, массивов и строк, где это возможно. LabVIEW может передать их в DLL, но это продвинутая тема и лучше всего работает, когда разработчик LabVIEW также знает C, что не всегда будет так.
есть вопрос здесь. Я не хочу заканчивать с чем-то, что специфично для LabView, и кажется, что LabView может получить доступ к DLL, если они используют stdcall. Dll, как это будет вызываться из VB или другого программного обеспечения Windows, а также то,что я снимаю.
Я не уверен, что это возможность доступа к COM-интерфейсу, но был бы признателен за более подробную информацию о том, как это будет выглядеть для моего приложения.