nitulandia

Hello all, LV ver in use: 8.2 1) I have a stand-alone app ("GETFILES.exe") that every X num of mins gets a bunch of files from a database, and copies them over to my machine -let's say to "folder Y"- 2) I'm writing an app that will look into "folder Y" every so often, and then will copy whatever files it finds to another location. There is a potential case in the scenario from above on which my app could try to copy a file that it is not fully downloaded just yet: The "GETFILES.exe" is in the middle of downloading a file, and my app happens to be looking for files at that instance. Before I copy the file over, I would like to make sure no other process is doing anything with it. Any suggestions as to how to accomplish this in LabVIEW? Based on some reading I've done, they recommend I open the file first, and the claim is that I should get an error if the file is still being transferred. I've tried doing this, however, the OpenFile VI does not return any errors, even if the file is in the middle of the transfer. Any pointers will be appreciated much. Cheers, edp

Hello, I'm

I'm still using LV 8.2, therefore, I couldn't see the solutions posted. Here's one way of accomplishing this (see attachment)

Hi Mark, Your suggestion, "the easiest way is just to include them with your app by going to the Source Files pane on the Build Specification for your DLL and add the assemblies you need to Always Included" has solved the issue :thumbup: I can now eliminate the work around I had put in place previously. Thank you much. Cheers, edp

Hello, General Info: - LV Ver in use: 8.2 - "Development PC" with Full development LabVIEW ver installed - "Production PC" with only the LV 8.2 RTE installed Test Details: - I have a "Dev" machine on which I'm running a .VI successfully; The .VI is a wrapper to .NET assemblies; All works as expected. - I have successfully compiled a LabVIEW DLL (MyTest.DLL), and runs as expected on my "Dev" machine. The first thing to note is that in the process of creating the LV DLL, LabVIEW creates a "DATA" folder at the location where the new DLL is created. Inside this "DATA" folder, I see that LabVIEW has put two .NET assemblies I use in my project. Just for you information, these two .net assemblies call several other DLLs, some by static and some dynamic reference. By the way, I know that I'm dealing with a total of at least 10 .NET assemblies, all of them which were included in my LV project. Hopefully what I wrote above makes sense...if not, please let me know and I'll try to provide more clarification. - Next I copy MyTest.DLL to the "Production PC" along with the DATA folder created. - When I try to run the test on the "Production PC", an exception is generated by one of the .NET dLLs: it complains that a .NET DLL could not be found at the "DATA" folder. If I manually copy the .NET DLL to the "DATA" folder, all works as expected. A few weeks ago I had posted something similar, however, this time around the post is a bit different. When I proceed to create my LabVIEW DLL, it appears that LV knows that I'll be using two .net assemblies, but doesn't know that those assemblies will use some other .NET assemblies being called by reference. I have put a work-around in my code, where I programatically copy some of these DLLs to the DATA folder if they are needed. Regardless, can any of you comment on the behavior described above? And, I'm also curious about the following: why does LabVIEW create a DATA folder in the process of outputing any given DLL ? I look forward to your comments. Cheers, edp

Hello Norbert, The following is probably not going to help, so, in advanced, apologies for that. I'm using LV 8.20, and have successfully written wrappers to .NET assemblies. If I can suggest something: wire the error clusters (ins and outs) and run it in debug mode. The other thing to try is to re-wire the constructor node on each VI; In short, re-select the .NET assembly. While I was working on my project, my vendor kept providing updates to the .NET assemblies I was using, and in one instance I saw an error where I could not see properties... and the reason for that was that I had forgotten to link my VI to the newer .NET provided. Cheers, edp

Hello, I'm trying to educate myself a bit on accessing databases from LabVIEW. I'm working on a project on which I'll need to get data from a database (MySQL) - a pretty simple task - Anyhow, I found LabSQL http://jeffreytravis.com/lost/labsql.html and this is what I'll use as it meets my needs. I'm curious about the following: Why would a user go with NI's LabVIEW Database Connectivity Toolkit vs LabSQL ? If any of you readers have used the toolkit before, could you list some of the benefits? I don't know much about the toolkit, other than what I've found on NI's webpage: http://www.ni.com/toolkits/lv_db_conn.htm I'm having a hard time understanding why would someone pay for software when is available free of charge? I'm not trying to insult anyone here. Maybe my lack of understanding of features available in the toolkit made me wonder that. I look forward to your comments. Cheers,

QUOTE (rolfk @ Feb 5 2009, 02:22 AM) Hi Rolf, Thanks for sharing those .NET details. I'm no longer seeing the issue where LabVIEW wants to see certain DLLs in random paths. My vendor has fixed this issue. The change made: they've given me an installer (as opposed to a .zip folder with all of the .NET assemblies in there). What happens with the installer is that it registers/installs the .NET assemblies in the GAC folder (C:\WINDOWS\assembly). Before the installer, and with the previous versions of the .NET assemblies I'm not sure what was going on. Now, this is interesting as well: every time I get an update from my vendor, I have to manually re-link the constructor in every single VI I have created (wrappers to .NET assembly). Based on my what I've read, this is the nature of .NET assemblies. I had read in some other thread (on the web somewhere) that this was a LabVIEW issue, however, based on my limited knowledge and understanding of .NET assemblies, it seems like this is not a bug. In short, .NET assemblies don't behave like "normal" dlls. I'll post more details If I run into more weirdness. Regardless, I want to thank you all for the comments. Cheers, Eddie

QUOTE (mesmith @ Jan 29 2009, 09:42 AM) The solution (at this point the solution is conceptual, not implemented/tested just yet). The problem seems to be with one of the .NET assemblies provided by the vendor. Under "normal circumstances", these .dlls are installed (obviously with an installer) as part of some application. Clearly, a path is created and these DLLs look for some files at runtime at the expected path. In my case I don't have this application installed, I'm just trying to make use of the .dlls. Once I get a new set of DLLs from my vendor I'll post the test results. By the way, I think I may run into a problem (this appears to be a real LV issue) when the new version of the assembly is provided. I'll have to re-link all of my wrappers to the new DLL. I read this on some other LAVA thread. LAVA is cool.

QUOTE (mesmith @ Jan 28 2009, 09:47 PM) Hi, First, thank you for the comments. In regards to your comment, yes, that is the observed behavior. "OK - so if you put the DLL in the requested path, it works the next time you call the VI - but will it fail again later looking for the same DLL but now in a different path? That's what I think I read". It is very likely that this will fail again if I shut down-and-up my machine, however, I'm not able to reproduce this all the time. The only way I can get it to fail every time is if I completely remove the .dll from the last expected path. And yes, I have all the vendor's dlls in the same location where my VIs are. And, all of these have also been added to my LV project. BTW, my vendor is aware of the issue... and of course, the "finger pointing battle" has already begun. They claim that the issue here is LabVIEW :-) I'm planning on posting the solution to this issue once the root cause is found. For now I need to educate myself a little more on .NET assemblies, thanks for the link. Cheers, Eddie

QUOTE (nitulandia @ Jan 28 2009, 04:14 PM) Hello Mark, This is the error msg: "Error accessing property EieParallelTest.TestManager.Api.Interface.IEnvironment.Controllers of ObjectId handle: 0x5A5115C for obj 0x2B8BB1[EieParallelTest.TestManager.Environment] in domain [LabVIEW Domain for Run] and thread 7464, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. Inner Exception: System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Documents and Settings\user123\ABC.dll' or one of its dependencies. The system cannot find the file specified. ) in PROOF OF CONCEPT2.vi" The error code returned is 1172. If I manually put the ABC.dll in the path, my VI will work.

QUOTE (mesmith @ Jan 28 2009, 03:24 PM) Hi Mark, I'll post the error msg once I get it to occurr again. I'm not able to replicate the error pattern from run to run. The only "pattern-like" I've found is that if I shut my machine down-and-up, and then try to run my VIs, this is when it may (or may not) happen. Some more details: -The .NET DLLs are in the same folder location as my VIs. -I've also added the DLLs and VIs to My LV prj

Hello Mark, The errors are being generated while the VI is running. I've attached a .bmp which shows for example, where the exception is coming from, and the error msg described previously. Note that it IS NOT always the same method that throws the exception, however, it seems that it is always complaining about the same DLL though. In other words, even though I have 7-8 dlls, LabVIEW wants to see the same abc.dll in different locations.

Hello, My LV ver: 8.2 A vendor has given me some instrument drivers in the form of .NET DLLs (several DLLs). I've been able to sucessfully write wrappers (.VIs) around them, and all seem to be working fine. The issue I'm running into is the following: very randomly, an exception is thrown by the DLLs (I still don't know why that is). The LabVIEW error describes more or less the following: "Cannot find abc.dll at C:\Program Files\etc etc" . If I manually copy the DLL to the expected path all works fine once again. However, the error will show up again after a while, and this time, it wants the abc.dll at some other location. Again, if I manually copy the DLL to the expected path all works ok. I've looked into "registering" the .NET DLLs up front, but so far have not been able to find a way to do this. LAVA gurus, any pointers will be much appreciated.

QUOTE (crelf @ Jan 15 2009, 10:29 AM) The pop-up name is "Three button dialog.vi" This VI is part of the LV library, under the "Dialog & User Interface palette". I'm still seeing the same behavior. As mentioned previously, this is not a show stopper. This is the microsoft article that led me to the registry solution: http://support.microsoft.com/kb/886217

QUOTE (crelf @ Jan 15 2009, 10:29 AM) The pop-up name is "Three button dialog.vi" This VI is part of the LV library, under the "Dialog & User Interface palette". I'm still seeing the same behavior. As mentioned previously, this is not a show stopper. This is the microsoft article that led me to the registry solution: http://support.microsoft.com/kb/886217

QUOTE (crelf @ Jan 14 2009, 03:07 PM) Hello Crelf, I modified my windows registry, and put the default value back (not zero). Then I tried your suggestion, and in my case it did not make a difference, the pop-up was still shown running on the back of my sequencer. I've tried several things: if I set the VI properties/window appearance to be shown when loaded this works. The issue here is that the entire VI front panel is brought to the front, this is not the behavior I'm after, I only want the pop-up shown. Regardless, thank you for the suggestion.

QUOTE (crelf @ Jan 14 2009, 03:07 PM) Hello Crelf, I modified my windows registry, and put the default value back (not zero). Then I tried your suggestion, and in my case it did not make a difference, the pop-up was still shown running on the back of my sequencer. I've tried several things: if I set the VI properties/window appearance to be shown when loaded this works. The issue here is that the entire VI front panel is brought to the front, this is not the behavior I'm after, I only want the pop-up shown. Regardless, thank you for the suggestion.

General Details: * LV version in use: 8.2.0 * In the code I'm using a few LabVIEW popups. * I'm compiling the code on a "development" machine, and distributing the LV DLLs to "production" PCs. * I have just added a new "production" PC with only the LV RTE installed. Clearly, I'm interested in running LV DLLs, and not the source code. My test scenario is the following: I have a home-made sequencer (similar to TestStand) which loads and runs my LV DLL. The issue I was having is that when I ran my tests on that new "production PC", the LabVIEW popups would always be on the back of my sequencer (not the most front) . In my code, I was using the appropriate properties to enforce that the LV popup would run as the most front. Well, the fix to this was a Windows registry setting: My Computer/HKEY_CURRENT_USER/Control Panel/Desktop/ForegroundLockTimeout (set the value to 0 hex) If you need more details you can find them on the web (google search, etc) For LAVA gurus, are there any other known solutions to the issue I've described? I would rather stay away from making mods to the registry keys.

General Details: * LV version in use: 8.2.0 * In the code I'm using a few LabVIEW popus. * I'm compiling the code on a "development" machine, and distributing the LV DLLs to "production" PCs. * I have just added a new "production" PC with only the LV RTE installed. Clearly, I'm interested in running LV DLLs, and not the source code. My test scenario is the following: I have a home-made sequencer (similar to TestStand) which loads and runs my LV DLL. The issue I was having is that when I ran my tests on that new "production PC", the LabVIEW popus would always be on the back of my sequencer (not the most front) . In my code, I was using the appropriate properties to enforce that the LV popup would run as the most front. Well, the fix to this was a Windows registry setting: My Computer/HKEY_CURRENT_USER/Control Panel/Desktop/ForegroundLockTimeout (set the value to 0 hex) If you need more details you can find them on the web (google search, etc) For LAVA gurus, are there any other known solutions to the issue I've described? I would rather stay away from making mods to the registry keys.