Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Bobillier last won the day on January 28 2014

Bobillier had the most liked content!

About Bobillier

  • Birthday 01/23/1964

Profile Information

  • Gender
  • Location
    Rennes France

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Bobillier's Achievements


Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Reacting Well Rare
  • Dedicated Rare

Recent Badges



  1. Hi pawhan11 Few days ago I have experiment one similar problem about exe and a .NET compoment (look here). I have solved it by adding a small file before my exe to indicate what assembly runtime version using. I'm not sure than you can use similar thing to solve your problem (LV11 refer natively to .NET 3.5), but perhaspse that can run. I have see something about that here Step 1: create a texte file named Labview.exe.config Step2: Place the text below in it <?xml version ="1.0"?> <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.8"/> </startup> </configuration> Take care about supportedRuntime version number because it must be corresponding to your .NET constructor. Step3 : Save this file in same directory than your Labview version, and restart LabVIEW Step4 : Rebuild your assembly.
  2. To be more efficient with the workaround, follow this procedure: 1) Copy the file "Your Application Name.exe.config" and Post-build Action.vi in your project folder. 2) Rename "Your Application Name.exe.config" with the good name of your application 3) Add it to your project. 4) In executable construction windows, add "Your Application Name.exe.config" to the source files\ always include list 5) In executable construction windows, select Post-build Action.vi in "Pre and Post build Action 6) Run construction. The post build vi is just to move "Your Application Name.exe.config" from data folder to those parent application folders automatically. Without it let it to data folder and you need to move it manually Post-Build Action.vi Your Application Name.exe.config
  3. On my machine I have V1.0, V1.1, V2.0, V3.0, V3.5 and V4.0.30319 installed. But If LV 2011 use 3.5,why I have the Labview tool to identify "Assembly .NET in memory" who refer to V4.0 ? Wonderful It's exactly the problem origine. Like said ShaunR if LV2011 needs 3.5, and if IDE refers to 4.0, I will need to add the Application.exe.config file in the application folder to force exe to use 4.0. Thanks to all
  4. Hi Rolf It's first time I use .NET and I'm newbee about those technology . At start I just want send email through SMTP TLS in old application LV2011. Like secure SMTP is not present in LV2011, I have found one example who use them with .NET Like I said before this example run OK (with my own account (not ggogle)), but just in my LV IDE. I 'm not sure to understand what is signification of "strongly named" but when I use the Labview tool to identify "Assembly .NET in memory" I obtain this link: I think it's in GAC but i'm not sure and If it's the case , like you said "Something is wrong" , but what ?
  5. Hi I have created one program who call a DotNet assembly component (.NET4 system.dll) and all ok in my LV2011 development ide. But when I create EXE with it, each time I run the program it calls me .Net ddl path. I do that on the same PC. If I indicate the path, the program loads it and runs correctly. It's a bit painful and not very professional to do that each time. To solve this, I have tried lots of work around but without success. 1) Add Dll caller Vi directly in project folder . (intialy in my user folder) 2) Add a specific .ini file where I have added a key for the search path (viSearchPath= "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089") to Help LV to found assembly. 3) Add DLL in my exe construction in data folder 4) etc etc... I have read and test lots of things on NI website but it's not always clear for me. If someone can give me a good procedure it will be christmas for me. Eric
  6. Thanks Antoine I have tested your version, but it seems that it did not work if you have more levels of stacked case structures. I think it's because you don't use "Traverse for GObject.vi " like me. My approach is to select tunnels before applying the change and not the case structure itself. Here my new version with few corrections about your first remarks Set Tunnels Default Values.vi
  7. Thanks Antoine I have not enough test it before propose it. Sorry I working on to correct bug when i receive your last message and modified version. Unfortunely, i can't test it because it's in LV2019 and I only have LV2018. Is there possible to have it in LV2018 ? Thanks
  8. Oups minor correction to avoid debug windows when loaded. Set Tunnels Default Values.vi
  9. Here the QD Instalation: Save it in quick drop plugins folder Usage: Select few unwired tunnels in one or few stached case structure and run the QD Short-cut [U] (can be modify in the vi documentation texte) LV2018 Set Tunnels Default Values.vi
  10. Yes, It's exactly what I'm looking for. Thanks Now I will try to do QD to automatically do this with few tunnels in few stacked case structures.
  11. Hi Do you know if there is a way to switch unwired tunnels to their default values by scripting?
  12. Thanks for this idea. Unfortunately this type of mechanism does not exist natively in the DQMH framework. A future evolution perhaps? I will suggest it on the DQMH forum. Either way, it would be nice if the LabVIEW IDE offered it natively without needing to code it in programs. It's like for the vi which have Modal windows and which we forget to close before launching their proprietary program and which blocks the front panel and prevents us from all actions. Also a small keyboard shortcut in the IDE would be useful.
  13. Ok I will make test with Task Manager, but like it's similar tool, I think than I obtein same result.
  14. Ok Thanks Ensegre. But I have forgotten one detail, The DQMH 5 uses "Start asynchronous call.vi", which load and forget clones. In normal usages, it's DQMH that includes a mechanism to associate the clone to one numerical identifier (ID) and not the clone ref. When you when stopping the clone, you send specific command with ID. But in some cases of problems, the ID can be kill without stopping the clone. In this case, the clone stays in memory, and there is no simple possibility to stop it. I show it in memory with this kind of tool, but when I ask it to kill clone Vi, that generates one error message. The reason, I think, is that the clones are in "Load, run and forget" mechanism and it's not possible to kill them directly. And like until one clone ref run, I can't pass source clone vi in edit mode. The only way stay to close the project, but it's a bit not practical.
  15. Like this: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Abort-Asynchronous-Called-VIs-when-the-parent-stops/idi-p/1734792?profile.language=fr
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.