LogMAN

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.

My understanding of this is far to basic, but maybe this thread is of interest for you: http://lavag.org/topic/17123-lvoop-with-dvrs-to-reduce-memory-copies-sanity-check

You should be able to view the code of the toolkit. All VIs are basically wrapper around an ADODB Connection. The function you use to receive parameters does that on purpose (using ADODB functions!), but only if the database supports that (pros & cons are listed in that VI too). There is a whitepaper from NI that describes the DCT: http://www.ni.com/white-paper/3563/en/ One statement says: Now if there is a native way to receive a list of stored procedures using 'ADO-compilant OLE DB provider or ODBC driver', you could write an idea in the Idea Exchange.

No. Your current implementation is as native as it can get.

Do you use strict-typedefs for your properties? Did you try to replace the VIs by their properties after saving for previous version? Some month ago I ran into various problems related to property nodes. In LV2011 the IDE got very slow and almost unresponsive... No problem without properties... Anyways, I reached a point where the entire IDE would just crash at load time for class private data! So I upgraded that particular project to LV2013 where I realized an odd behavior (that has been there even in LV2011, but did not catch my eye until then): If you wire a strict typedef from a property-node to a VI with the same typedef, a coercion dot will occur once you change a font in that typedef, or anything that is only available for strict-typedef. In LV2013 you get an explaination for the connected data types in the context help. The source is presented as type of 'error in' or some other non-related type... Once you place the VI instead of the property node, everything is fine. According to NI that has something to do with the way LabVIEW updates the typedef. I did not get much details, but basically the property node remains with an 'old' or rather 'partial-new' version of the typedef, since a property has no FP, while the VI is updated with the entire 'new' typedef, thus leaving the IDE with "two" typedef revisions at the same time... See the picture and notice that there is a coercion dot and the Main-VI is not broken, even though the context help makes me ... ... ... ! (this is LV2013) Also notice, that the same implementation without property-node has no coercion dot! Not to mention that the terminal data type according to the context help is of type 'error in', but correctly named 'Strict1' and the connected wire data type represents the correct type <there is no emote to display how I feel about this, maybe if LavaG had something... exploding... no?> This is (according to NI and my experience so far) just a IDE issue and has no known effect to the build exe (code is not even broken). NI is informed of course, but there will not be an update to this until LV2014 or later. Anyways, I wonder if what you experience might be related (LV2010 could have even more issues with this than LV2011). From what you've written, it kind of fits.

The easiest solution would be to rename the private method to "PrivateReadDevice.vi", as the private interface can still be changed anytime without side effects on implementations (like linking issues). However your example should be two seperate classes in my opinion: One for serialized access (i.e. the implementation of a driver) and a second class for access in terms of a messaging system to an async. state-machine/process which implements the driver.

I did not have a chance to test it yet, but maybe thats worth a look? http://lavag.org/topic/17024-rex-remote-export-framework-and-remote-events/

shoneill is right, having a convention is a very important thing. ( I used to change my 'convention' because of various, situational and sometimes stupid reasons, so code got messy or time run out ) There are some things to consider, this is what I could guess of (speaking in general, not specifically for libraries or classes): Prefixes -> Use libraries/classes instead (you'll get a namespace 'Library.lvlib::Member.vi'), how would that look with prefixes: 'prefix_Library.lvlib::prefix_Member.vi' ( )... You have to organize the files on disk to prevent name conflicts though. If there is a need to prefix everything, just change the library/class name (linking issues are conveniantly easy to solve this way in my experience). Spaces -> One of the most obvious things that make LabVIEW different to languages like C. Good for starters and easy to read. However if you build DLL files (or enable ActiveX afaik), spaces are a problem. CamelCase -> Sometimes hard to read and maintain, but in combination with libraries the most flexible one in my opinion. Makes it easier to reason with people from the other side. CamelCase in combination with libraries/classes is what I actually use, even though it is sometimes painfull to stick to ( ever batch-created accessor VIs to class members? I'm always having fun renaming all of them ). As you're asking for libraries & classes specifically, I don't use prefixes (they tend to change on my end...) and I have trouble to write well-named VIs including spaces (would you write 'Write to Disk' or 'Write To Disk'? Therefore CamelCase is a good solution for me ( 'WriteToDisk' ). I also no longer create subfolders on disk to organize class files, but virtual folders in the project only (how I hated to move files because they are in a different category for some stupid reason...). Also libraries (*.lvlib) and class (*.lvclass) files are within their particular subfolder on disk. If I now move a library/class to a different section, I just have to drag the entire folder. This handles quite well in SVN too. Would be interesting to see how everybody else handles such things... EDIT: Error in database, but still posted? Sorry for this tripple-post.

I have never implemented this function with a remote target, so I can only reason with the little information I have: Telling from the help, your solution should work fine. However, it says: vi path accepts a string containing the name of the VI... and furthermore Note If you specify a remote application instance with application reference, the path is interpreted on the remote machine in the context of the remote file system... It explicitly says path and not string or path, so I'm not sure if your problem is the expected behavior, or a bug (I could argument for either of them). Anyways, in my opinion the application instance perfectly identifies the target and there should be no problem with either a string or a path.

The last time I had such an issue, it was related to the 'Seperate Compiled Code' option in combination with revision control: I reverted one of my components in SVN and for some reason it has not been recompiled automatically (broken-unbroken issue)... After hours of searching, an NI engineer suggested to clear the compiled object cache, which solved the problem entirely. Not sure if that's related.

I may have got confused. So this is basically a different implementation of the actor model? The only one I've ever used up till now is the "Actor Framework" that is now also shipped with LabVIEW. http://lavag.org/files/file/220-messenging/ Never mind. Memo to myself: Actor Framework != Only possible way & RTFM. It's fine, I too often consider more advanced implementations over the ones which are "recommended". It is just harder to learn multiple specialized modules over a single one for beginner (like me for this one). The NI version does everything, using standard tools that are shipped with LabVIEW (even though it is far away from being "easy to understand for beginner"). I favor your implementation of asynchronous calls for scalability. The NI version is good, but 3 or 4 parallel loops in a single VI are to much for me to stay calm ( always trying to find a "better" solution ). I was trying to say the exact same thing, however my initial statement has become irrelevant for this matter. You are not bypassing actor messages with your message system, it's just a different implementation of the actor model. I was comparing apples with oranges and got confused about something that was missing... Thinking about it from the new point of view, your implementation might be less complex than the "Actor Framework" I was talking about earlier. The name sounds familiar and I think he is the one (big guy with full beard). It's too long ago for me to be sure though. I just remembered a warning about bypassing the actor messaging using any kind of secondary system, since that would eliminate the idea behind the actor framework model. But that was completely related to the "Actor Framework" and some crazy complex project (and yes, it was way to complicated). Now I'm getting excited to try the Messaging package... So many things I want to know, but no time at all

I tested it and it works fine. One dependency was missing, but this is easy to solve: http://lavag.org/files/file/235-cyclic-table-probes/ Like neil, my time is limited right now and this is also not my specialty. I'll give my opinions anyways (notice, I had like 10min for this): I think your code is much easier to extend (while maintaining readability that is) than the NI version, but the complexity is on a much higher level (Actor Framework, JKI State Machine, Messaging Library). Anyways, there is one thing bothering me regarding the coupling of your actors. An actor is defined by its messages. You could bypass that by sharing references or reference-like objects that allow direct access to actor-specific data or functions, thus eliminating the need to use any actor message furthermore. If I understand your code correctly, the actor messaging system is bypassed by the the messaging library. Now would it make any difference if you call an asynchronous VI instead of the actors? There has been a webcast about a big project that has been solved using the actor framework, but I can't recall the name or find it... It involved a flexible UI where some actors are bypassed, as well as sharing actor objects with realtime targets and network sharing. The presenter did a very good job to reason about the downside of some stuff they did. Does somebody know which webcast I mean? (NI Week?) I hope my explaination is understandable. Maybe some actor framework guru could give his opinions. Feel free to correct me.

Yes, give me a tongue twister My guess would be: "Data Value Reference Paced Object Oriented Programming" short: DVRPOOP Trying to get back on topic: It's just a ByRef implementation of OOP, so no popular or super fancy name to it. The standard implementation would be ByVal.

I don't see any obvious reason why the data should be loss, however from these pictures it is hard to get many clues. Did you check if there is any awkward call to your "Destroy" VI, that could lead to your situation? -> Check any parallel thread. How does your "copy" function work? -> I assume you are building an entire new DVR. What is the scope of the queue you want to add the element? -> As far as I know, a DVR is valid until no VI makes use of it anymore. Check if the references are valid and at which time they become invalid. Last but not least: This is not standard LabVIEW OOP, as it would be impossible to wire a DVR directly to a class method. Are you using GOOP? Could you provide a code sample, so we would be able to confirm that behaviour?

I too experience a memory leak of seemingly 4 - 16KB/s on a XP machine with LabVIEW 2013 RT. The leak will cause a very slow application after several hours (after approx. 5-6h), even though the memory is far away from full (still more than 2GB left). I remember something about queues allocating memory whenever you try to access them by name, about 4Bytes for each time or so?... Found it: http://digital.ni.com/public.nsf/allkb/1EBEA74610577B8A86257156006985CB Searching the internet further shows interesting topics (didn't try anything yet). AQ gave an interesting answer here: http://forums.ni.com/t5/LabVIEW/Obtain-Queue-memory-leak/m-p/1644744#M590534 Question is: Do we rapidly obtain queues by name without releasing them? Also: As Semaphores are using queues internally they too are worth checking. I'm just throwing my thoughts in here, but maybe you are experiencing a similar or even the same issue.

Interesting task, some VIs are missing though (from your user.lib), but I get the critical part now. As far as I know there is no way to pass a delegate from LabVIEW to a function (as there are no raw delegates in LabVIEW). Also, even though the parameter is called 'asyncCallback', it is not an event callback, but just a parameter you could pass (any?) delegate to. The delegate could be registered as an event by the caller. I searched the internet and found a similar topic: http://forums.ni.com/t5/LabVIEW/How-do-I-configure-NET-SOAPSender-AsyncCallback-in-LabVIEW/td-p/284364 The first answer states: I think this is still true. The only option I see for this is to write your own wrapper that internally handles the delegate and provides an event for LabVIEW to register to. Of course you would also have to wrap the method you want to call in order to provide a method without the delegate parameter. I'm quite sure I've seen a similar topic here before... I guess...

I can't give a solution for your specific problem, but .net callbacks are easy to understand: - Place the Register Event Callback node from the .NET palette into your VI - Wire the .NET class reference to the Event input (the third connector from top-left! not the first!) -> Now you can select an event from the drop-down box where all available Events are listed - Once you've selected your event, rightclick the VI Ref terminal and select Create Callback VI - Do whatever you want in the callback VI (like trigger a LabVIEW event) Now whenever the event is fired, your callback VI is called... Try it with a message window Hint: Wire some data to the User Parameter input of the Register Event Callback node and re-create the callback VI. This is how you could send a LabVIEW event refnum (or any type of data) into a callback VI. Hope that helps. Upload your VI if you need help for your specific solution. EDIT: Ehem, I hate to post links but: http://zone.ni.com/reference/en-XX/help/371361J-01/lvcomm/reg_event_callback/ https://decibel.ni.com/content/docs/DOC-9161