LabVIEW bloquant les signaux Qt?

Question

J'ai un programme LabVIEW 8.6 qui utilise une DLL écrite en Qt; la DLL écoute un port TCP pour les messages entrants et met à jour certaines données internes. Mon programme LabVIEW appelle parfois la DLL pour lire les données internes. La DLL fonctionne parfaitement (c'est-à-dire, reçoit des données du port TCP) avec un autre programme Qt. Cependant, cela ne fonctionne pas du tout avec mon programme LabVIEW.

J'ai attaché un débogueur à la DLL et je peux y voir les appels de LabVIEW - ma fonction pour obtenir les données internes est appelée et je peux la parcourir. Le code qui obtient les données du TCP n'est jamais appelé cependant; il semble que le signal pour les données entrantes sur le port TCP n'est jamais déclenché. Je sais que cela ressemble à un problème Qt mais la DLL fonctionne parfaitement avec un autre programme Qt. Malheureusement, il échoue lamentablement avec LabVIEW.

Une théorie:

• La boucle d'événements ne fonctionne pas lorsque LabVIEW appelle la DLL

  • Dans la fonction run de() DLL Qt, je l'appelle socket-> waitForDisconnected(). Peut-être que la DLL ne traite pas les événements entrants car la boucle d'événements n'est pas en cours d'exécution? Si je l'appelle exec() pour lancer la boucle d'événements, les accidents de LabVIEW (LabVIEW 8.6 Development System a rencontré un problème et doit fermer ".):

 
    AppName: labview.exe  AppVer: 8.6.0.4001  ModName: qtcored4.dll 
    ModVer: 4.5.1.0  Offset: 001af21a 

• Peut-être quand je l'appelle la DLL provenant d'un autre programme Qt, la boucle d'événements de ce programme permet au signal TCP d'être vu par la DLL, mais le lancement de la boucle d'événements dans la DLL annule LabVIEW

en cours d'exécution dans la DLL lorsque La bVIEW est le programme appelant?

EDIT trace de débogage de l'appel exec():

QThread::exec() -> eventLoop.exec() -> if (qApp->thread() == thread()) 

in the call to 

QObject::thread() { 
    return d_func()->threadData->thread; 
} 

La Q_DECLARE_PRIVATE macro (QObject), le second appel, déclenche le plantage.

EDIT 17 août 2009: mise à jour du statut

Après deux jours d'essayer différentes façons d'obtenir ce travail j'ai décidé de mettre en œuvre un écouteur TCP directement dans LabVIEW. Mon application LabVIEW envoie des données via la DLL et reçoit des données via TCP. Tout fonctionne bien.

---

Cette question a été permuté sur http://forums.ni.com/ni/board/message?board.id=170&thread.id=431779

Answer 1

Pouvez-vous déboguer par exec() pour voir où il se bloque LabVIEW?

Vous pouvez également définir le débogage maximum dans LabVIEW dans la page de configuration du nœud de la bibliothèque d'appel. LabVIEW est fastidieux avec les DLL. Il peut être plus facile d'exécuter la DLL en tant que service (écrire un service qui exécute la boucle d'événements), puis demander à LabVIEW d'appeler une DLL qui récupère les données du service.

Answer 2

Old NI help note

Juste un coup de feu dans l'obscurité ... pourrait les données Qt est une partie de la démolir l'espace mémoire LV immédiatement après la boucle exec est commencé?

Answer 3

Vous n'avez probablement pas créé d'objet QApplication lorsque vous essayez d'appeler exec() dans QThread. Cela pourrait causer votre accident. Pour le problème principal, cependant, je dirais qu'il est très probable que vous n'obteniez aucune activité dans la DLL en raison de l'exécution de la boucle d'événements.

Answer 4

Vous devez modifier l'appel de la bibliothèque pour qu'il s'exécute dans n'importe quel thread de sorte que le thread de l'interface utilisateur puisse toujours exécuter la boucle d'événements.