Executables créés sous LabView 2011 pour Windows 10

[gerald.monin]

Bonjour, 

Nous avons Labview 2011 (32 bits) avec lequel nous avons développés des applications pour nos clients et qui fonctionnent parfaitement sous Windows 7 et 8, mais qui ne fonctionnent pas toujours sous Windows 10 (64-bits).

Quel moteur d'application faut-il installé sous Windows 10 (64-bits) pour faire fonctionner nos applications ?

Merci d'avance pour votre aide,

Gérald

[Michael.C]

Bonjour,

Tu trouveras toutes les informations nécessaires à ces deux liens :

-Drivers hardware utilisé (http://www.ni.com/white-paper/52818/fr/)

-Version de labview (http://digital.ni.com/public.nsf/allkb/B972242574D4BB99862575A7007520CB).

Bonne soirée,

Michael

[gerald.monin]

Bonjour Michael,

Merci pour ces liens et ces explications, mais c'est surtout pour la compatibilité du logiciel de développement avec Windows 10.

Pour ma part, je souhaiterais savoir si, chez un client avec Windows 10 - 64-bits, je dois installer le moteur d'application LVRT2011-32bits ou le LVRT2016-64bits, ou encore le LVRT2016-32bits ???

Merci beaucoup d'avance pour vos réponses.

Meilleures salutations,

Gérald

[Michael.C]

Le tableau fournit dans mon lien te montre les correspondances.

Après que ce soit l'environnement de développement ou le ru-time, à mon sens, les restrictions seront les mêmes donc le tableau est transposable.

Donc je te dirais que Non, tu ne pourras pas mettre LVRT2011 sur un poste sous windows 10, même si celui-ci marche, dans le temps, sa stabilité n'est pas garanti par NI.

Après en ce qui concerne la version 32 Bits ou 64 Bits, cela dépendra aussi de ton environnement de développement.

Si tu développes en 64Bits, il te faudra un runtime en 64 bits, sachant qu'un OS 64 Bits pourra acceuillir un RT 32et/ou 64Bits, alors qu'un OS 32 Bits, ne fera jamais que du 32 Bits.

J'espère avoir éclairer les dernières zones d'ombres.

Cdt,
Michael

[gerald.monin]

Bonjour, 

Alors après plusieurs essais, avec LVRT2011, LVRT2015, LVRT2016, versions 32 ou 64 bits, le résultat est toujours le même: l'application utilise jusqu'à plus d'1GB de RAM et la face-avant ne s'affiche jamais !

Plus étrange, une application générée sous Labview 7.1 fonctionne parfaitement avec le LVRT7.1 !!!

Je n'ai donc toujours pas de solution pour mes applications générées sous Labview 2011.

J'ai demandé au client de réinstaller son ordinateur. A suivre ...

Gérald

[Michael.C]

---

gerald.monin a écrit :

Bonjour, 

Alors après plusieurs essais, avec LVRT2011, LVRT2015, LVRT2016, versions 32 ou 64 bits, le résultat est toujours le même: l'application utilise jusqu'à plus d'1GB de RAM et la face-avant ne s'affiche jamais !

Plus étrange, une application générée sous Labview 7.1 fonctionne parfaitement avec le LVRT7.1 !!!

Je n'ai donc toujours pas de solution pour mes applications générées sous Labview 2011.

J'ai demandé au client de réinstaller son ordinateur. A suivre ...

Gérald

---

J'ai du mal à te suivre, je me demande si on partage la même vision des choses :

- Quand je parle de Labview (7.1 / 2011 / 2013 /2015 / ....), je fais référence à l'univers de développement labview qui te permet de développer du code, générer des exécutables, exécuter des exe développés à partir de labview

- Quand je parle de LVRT (labview runtime) (7.1 / 2011 / ....), il s'agit d'une bibliothèque déployée sur un PC hôte qui te permet uniquement d'exécuter un code compilé (tartanpion.exe) généré dans la version équivalent de Labview.

Enfin, en écrivant ces mots, je me demande, si tu parles pas d'une 3eme possibilité : LVRT = Labview Real Time, et là c'est encore autre chose 😄

Il faudrait vraiment que tu re-exposes clairement ton problème car là ça devient complexe on mélange les versions, les applications, et les OS...
Si on en revient au sujet initial, à partir des liens que je t'ai fourni, si tu veux travailler en développement sous Windows 10, il te faut aller sur du labview 2016. Si ton client veut migrer ces postes sous Windows 10, il te faut passer sous Labview 2016 pour la compatiblité des drivers d'instrumentation, et donc de ton côté il te faut un environnement de développement sous Labview 2016, et que tu fournisses au client le package Labview Runtime 2016, et les bibliothèques nécessaires à ton programme.

As tu valider le fonctionnement de ton application en mode développeur sous Windows 10, cela pourrait t'aiguiller sur la fonction qui bloque.

[gerald.monin]

Alors en effet, ça redemande un recentrage du problème 

J'ai un univers de développement Labview 2011 32 bits sous Windows 7 64 bits qui fonctionne parfaitement et avec lequel je génère des applications pour nos clients qui utilisent un moteur d'application LVRT (runtime engine) 2011.

Normalement tout va bien, sauf que j'ai un client qui a un Windows 10 Home 64-bits sur lequel, rien ne fonctionne. Je ne peux bien entendu pas y installer l'univers de développement Labview et de toute manière je n'ai pas de licence pour une version 2015 ou 2016. Et je sais que ça fonctionne chez d'autres clients sur Windows 10, mais généralement du Professionel et non du Home.

Voilà, j'espère que c'est un peu plus clair.

Merci pour vos réponses et propositions,

Gérald

[Michael.C]

Cool, je te remercie, c'est plus clair pour moi.
A partir de là, voici les points que je vérifierais si j'étais à ta place :

-> Les accès aux fichier en lecture/ecriture : une version Home de windows est par défaut plus restrictive pour "mieux" (on parle de windows là .... :D) sécuriser l'utilisateur. De manière globale, quand on utilise des fichiers en lecture/ecriture (log/fichier de configuration / ini ..) je préconise de ne pas installer son programme dans le répertoire "Program Files", mais dans un répertoire perso à la racine du disque dur. Ou sinon déplacer tous les fichiers nécessitant des droits de lecture /ecriture dans le répertoire document du profil Public.

-> Les configurations de Firewall : Une version "Home" est moins modulable au niveau des paramètres de liaison ethernet, cela pourrait générer une défaillance de ton programme sans remonter d'information. Es tu sur que tu gères bien la totalité des erreurs dans ton programme (fil d'erreur d etoutes les sous fonctions de cablé) ?