LogMAN

Yes, interfaces cannot be instanciated. You can find a good explaination on interfaces & abstract classes here: http://stackoverflow.com/a/1913185 Anyways, you could create your own implementation of ISldWorks in C#, build the .NET assembly and call it from LabVIEW. Depending on what you try to archive it might be easier to stick to C# entirely.

ISldWorks is an interface that does not actually implement any code and therefore has no functionality. You would have to implement that interface yourself in order to provide any functionality. Since that is the case, an implementation in LabVIEW is impossible (you cannot implement .NET interfaces in LabVIEW) This is an example in VB where you create an instance from SldWorks.Application which is an ActiveX object! In order to create an ActiveX instance use the function from following palette: Connectivity >> ActiveX >> Automation Open Create a constant as input and choose 'Select ActiveX Object'. You'll get a list of available ActiveX-Objects (this of course requires you to actually have them installed) You should definately look into that, but this has absolutely nothing to do with your .NET assemblies! Your basic approach is okay, but whenever you want to use an object, you have to create an instance of it (or have a function return it). You only provided a constant that defines the type and no instance. This is very difficult for me to describe, so here is an example: Try this out, it works EDIT: Before I forget, I found a link to a document which describes some detailes to the interface mentioned ealier: http://sw.fcsuper.com/index.php?name=UpDownload&req=getit&lid=157

Accessing .NET components without any documentation is like looking for a needle in a haystack... My guess is that you try to access a property which requires you to do something beforehand (like loading a document, or assigning that mysterious 'key') Could you provide your current implementation? Maybe even an example of what you are trying to do in a .NET language (some sort of example code)?

I cannot advice you as I've never done that before, however this article: http://stackoverflow.com/a/836689 describes a way to connect to a LDAP server via System.DirectoryServices.Protocols Hope that helps!

Stupid boss In a time before VIPM, an installer (or in my case a solid zip file) used to be a good solution, however since a couple of VIPM versions the feature to create packages is available even with the community version. Also still working is the OpenG package builder (however I recommend VIPM). Just try it, it works like a charm (but keep in mind: there are certain limitations because of the license). If you want to automate the process of updates you should get a license for VIPM and setup your own repository. Once you publish a new version everybody who is registered (also requires license) will see a * on the package. In terms of cost, the time spend to tell everybody that an update is available (meeting, or sending mail with everybody copy-pasting files) vs. sending a mail and everybody clicking 'update' in VIPM should be considered (again the VIPM solution is solid and tends to work where a manual task causes issues that could be avoided). In my case we send mails with a link to the new *.vip file, so it is only a matter of a couple of clicks.

You could still delete the existing one and create a new one, however it might be difficult to handle all the relinking... I remember something about an INI key to activate "hidden" functions for VI scripting (or rather node options which are considered unstable as they are still in development and thus haven't been released for public access)... Maybe someone knows what I'm talking about and could share their thoughts? ... or maybe I'm insane?

I cannot give you a final solution, however here is a snipped to access the items in a class private data control as well as the property definition folder (I can't change the name to write, but maybe a newer version of LabVIEW can do that?). This snipped does nothing useful, but you should be able to edit the class control and property folders with that.

Good question. I just tested on my system again with a much highter writing rate of 1ms: Now I get the exact same error. So as I understand it, write access guaranties that no other application can write the file, but it does not guaranty file access at all times (for example if another application reads the file). There is some sort of locking procedure to ensure no data is changed while reading, however I never got much into Windows file handling. I suggest you avoid this situation entirely by not accessing the file while writing to it. You could split files after a couple of MB or a certain time. Your current solution works too, but you can't tell how much data will have to be buffered before a write operation is possible again (so the system might run out of memory in the worse case). A database is the best choice for shared access (and it is quite easy to query data into Excel). Not entirely sure about TDMS (in terms of shared access), but for measurement data it is the most efficient.

I've tried to recreate your situation, but it seems to work for me. I can write while Excel (2010) has read-only access. I guess you should check your project again, if the file has been closed at some point. Here is the snippet of my Test-VI:

The dependency tree represents dependencies of your code, so if the DLL is not listed, it is not called (note that you might have to open one of the calling VIs in order to see the DLL under Dependencies). I'm currently wondering if you call the DLL directly in the Call Library Node, or if you manually specify the path... In the first case the path might be incorrect, in the second case you have to manually include the DLL with your project and deploy it with the executable (or rather you should have an installer for your DLL which takes care of that). Can you post a screenshot of your Call Library Node?

Here is the topic to the last question: http://lavag.org/topic/18282-edkdll-missing-eventhough-in-the-same-directory/

Maybe I'm missing something, but I don't see any edk.dll in your screenshots, just the edk.lib... Anyways, here are a couple of things you could try (assuming we are talking about a C DLL): -> Check if the Call Library Function does correctly point to the dll file (the path should be absolute imo) -> Look into the dependency tree if the file is listed there (it does not seem to be part of your project) -> Include the DLL file into your project -> Put the DLL next to the LabVIEW.exe (in Program FilesNational InstrumentsLabVIEW <version>) and try to start your application again (if it works you most likely have specified the DLL file name in the Call Library Function instead of the path)

I use the FTP: ftp://ftp.ni.com/support/softlib/labview/labview_runtime/

I've never done that, but I know there must be some option as you open a new ticket(might depend on the project). Some projects I follow provide a category called 'patches' to do such things. It seems there has been movement in your bug reports a couple of days ago, so that's a good sign I would say.

SourceForge is the best starting point in addition to this forum. However the project has not developed much over the last couple of years (there are quite a lot bugs filed with no development for almost a year). You could fork the project for your own purposes and upload patches as you file bug reports or maybe become part of the team yourself (if one of the members would allow that). The project might be dead, if none of the developers is interested in continuing it. In that case you could still fork the project, but there is little chance that anybody would benefit from patches (unless there is a way to fork a project and upload new versions to the VI Package Network...)

Your link explains a way to merge multiple sheets into a single workbook. You'll end up with a single workbook containing all data, same as before. The fact that you copy pieces differently does not change the fact that all data will be loaded into memory each time Excel loads the workbook (This is just how Excel works). Since the amount of data is the same, the problem will remain. You'll always experience the same limitations no matter how you build your workbook.

Wow, that's a new one for me... Could not belief at first, but it does work. Also just tested with a cluster containing strings and it works too (only if the cluster contains string and numeric types, but hey)! I've never used it for anything other than string or array of string up till now. Thanks for sharing Neil!

Thanks for the port! I've just tested on my machine with LV2011 and it works just fine. I was able to run the DEMO Command Sender.vi & DEMO Command Listener.vi in the development environment, as well as the sender in the IDE and the listener as separate executable. No relinking issues or any kind of problem with file versions this far. EDIT: Well ok, the Rex_Sprinboard library seems to miss some files for generating user icons and such. I guess that's just not available in LV2011. It's missing files from ..vi.libLabVIEW Icon API* Does my installation miss something?

My bad, I already forgot it had to be 64 columns each page... I've tested again and hit the same limitation on the 32-bit environment (with Excel using up to ~1.7GB of memory according to the Task Manager). Your system is more than sufficient for that operation (unless as rolfk correctly pointed out, you use the 32-bit environment). This is absolutely right. There is however one thing: Excel runs in a seperate process and owns a seperate virtual memory of 2GB while in 32-bit mode. So you can only create a workbook of that amount, if there is no memory leak in the LabVIEW application. In my case LabVIEW will take up to 500MB of memory, while Excel takes 1.7GB at the same time. If the references are not closed properly, you'll hit the limit much earlier, because LabVIEW itself runs out of memory. In my case the ActiveX node will throw an exception without anything running out of memory (well Excel is out of memory, but the application would not fail if I would handle the error). I have never tried to connect Excel over .NET... Worth a shot? jatinpatel1489: as already said a couple of posts ago: Make use of a database to keep that amout of data. If the data represents a large amount of measurement data, TDMS files are a way to go (I've tested with a single group + channel, with a file size ~7.5GB containing 1Billion values -> milliard for the european friends ). You can import portions of the data in Excel (or use a system like NI Diadem.. I've never used it though). If it must be Excel, there are other ways like linking Excel to the database (using a database connection). Last but not least you could switch to 64bit LabVIEW + 64bit Excel in order to unleash the full power of your system.

OK, here are the latest results: This time I let the application create 6 sheets with 20 columns, 600,000 rows each (writing 2 rows at a time). Notice that the values are of type DBL (same as before). Memory for Excel build up to 1,3 GB, but everything still works perfectly for me. My advice for you is to check if your RAM is sufficient, and review the implementation of the Excel ActiveX Interface. Be sure to close any open references! Without more information of your actual system (RAM) and at least a screenshot of your implementation, it is most difficult to give any more advice. If you could share a sample project that fails on your system, I could test on mine and may check for problems on the Excel Interface. Here is a screenshot of what I did (sorry, but I can't share the implementation of the Excel Interface)

Good point! I'll try that again tomorrow with multiple sheets... Does it work better if you save the workbook after each sheet?

LavaG is kidding me right now... Again: I would recommend a database, however one of my colleagues implemented something similar in the past (Export huge datasets from an database). You should carefully check the RAM utilization of your System (Do you keep all data in Excel + LabVIEW?). I tested on my machine (LV2011SP1) with 4GB RAM and Excel 2013 using the ActiveX Interface. Writing 64 columns with 600.000 random DBL numbers in a single sheet, one row at a time. It works like a charm, however Excel now uses 650MB RAM EDIT: Just checked what would happen if I build all data in LabVIEW first and then export to Excel: LabVIEW now takes ~1.6GB of memory + throws an error: LabVIEW Memory is full The issue is due to the 32bit environment, where a single process can only handle up to 2GB of virtual address space, see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366912(v=vs.85).aspx The issue is also caused by my way of memory management (reallocating memory each iteration!) Just checked again, I tried to copy all data at once, therefore trying to copy a contiguous block of 64x600.000 array elements (which might not be possible if there is no block large enough to contain this amount of data)... Anyways, the issue is clearly not Excel, but the implementation in LabVIEW (in my case).

This issue is quite common. You might be interested in this article: http://digital.ni.com/public.nsf/allkb/7DC537BCD6E679C3862577D9007B799E It describes two Workarounds, where the first one matches your solution. I preffer the second workaround, because it is easier to implement into the application itself (create if not exists).

Could you provide an example project? There have certainly been memory leaks with some .NET libraries ( Ping for example ), but it is hard to tell without seeing the actual implementation. However the usual issue is related to references that are not released ( using the 'Close Reference' function from .NET palette ). I've attached a code example with two implementations of the same function ( System.Xml.XmlDocument ), one releases the reference, the other not. Disable either of them and watch the memory usage.

I know these figures very well. I would like to see the code, but my current system does not have a LV2013 installation. Do you run your code on a standard OS/Hardware? (e.g.: Windows 7 on PC) For now I assume you do: General purpose OS and Hardware do not guaranty real-time capabilities. So the kernel will pause any thread whenever it sees fit. In my past tests the time sometimes spiked up to 400ms instead of the required 10ms, resulting in such graphs (even if the priority is set to 'critical'). Now you could let an external hardware do the acquisition and stream directly to disk. There might be other solutions though.