LogMAN

You're right, the total number of classes increases. I should have written "..reduce the number of classes in your current project..". You'll of course have to implement the Actor in another project. I've attached two pictures to clarify what I mean. Left(top) is the current situation, right(bottom) is the example with an interface. Blue is one project, green another.

How about making Actor B an interface and use the factory pattern? If Actor B were an interface it would not have any dependencies to Actor C, since that would imply implementation. Now if you test Actor A in isolation it would in fact load the interface of Actor B into memory (cannot be avoided due to a static dependency), but the actual implementation of Actor B (that causes more dependencies to load) is not necessary. I have little experience with AF, but in my opinion using interfaces and the factory pattern should drastically reduce the number of classes in your project (you would "only" need the interfaces and all Message classes which belong to them). The actual implementation can be done seperately.

I recently ran into a similar problem and solved it by installing the NI-IMAQdx driver based on this document: http://digital.ni.com/public.nsf/allkb/0564022DAFF513D2862579490057D42E The NI-IMAQdx driver software is needed to use third-party image acquisition devices

Thanks for the feedback guys! Now to the Moderators/Administrators: Can we expect a solution any time soon? EDIT: Maybe there is something we could help with? I can now place funny characters in your name and see what happens if I quote you? You loose even more characters

This is exactly the point. You can find a way to solve the immediate issue, however the initial problem remains. When you talk about 'repository' do you mean a repository as in SCC? If that's the case, how can a change on your local checkout violate anything in the repository? If that's not the case your file/folder structure now has a known issue There are many ways to solve that problem. First of all, the issue is related to long path names, so you want to have a short absolute path to your project and short relative path in your project directory. I have a local directory on a secondary HD 'B:\projects' which is the root path for all of my projects. I checkout my projects from SVN, but only a a specific branch, or the trunk (else the hierarchy is to extensive). So one project could have the absolute path 'B:\Projects\MyProject'. Short enough. Next we need a clean project structure to minimize file paths. In my case that would be: ..\Builds <- not under SCC ..\Documentation ..\Examples ..\Resources ..\Sources ..\<project>.lvproj All VIs, classes, etc... are placed within the Sources directory (either the sources are in the 'Sources' directory, or somewhere in the LabVIEW installation folder). So let me count characters and I got 'B:\projects\MyProject\Sources\' => 30 plus, minus the length of my project name. Now since I follow this layout, there have been no more problems with path length. However this requires that any files which are placed under 'Sources' are named properly (don't try to tell a story in the file name!). Also there is a rule of having at most two more directory levels (which is fine, since the project is fully capable of organizing sources using virtual folders). As example: All files related to a class are placed into a single folder, thus even with long file names it is not likely to hit the 256 character limit.

Since a couple of days some pages show strange behavior with unprintable characters. The same pages were fine before. Here are two examples: http://lavag.org/topic/17783-continuous-measurement-and-logging-redone-with-“messengingâ€-actors/ http://lavag.org/topic/10729-labview-idea-exchange/page-5#entry110225 Is this problem visible to all, or is it just me?

Okay, I start again by reading your initial post and ignoring any reply (except yours). Please be aware that this post is a pure brainstormer from my side and is in no way implemented by myself. Also you should know that I always brainstorm beginning with the basics and without limitations on changing entire structures. Since I don't have your current implementation at my disposal, my brain might get a bit out of control, but I try to stick as close to your situation as possible: First of all, we want to decouple implementations between sender and receiver. This requires a common 'language' between the systems. We don't want to go down to string handling and already have some sort of messaging system implemented which allows transmission of objects. Let me jump into your last post for now: Decoupling a class from it's implementation is just not possible by design! A class provides its own set of variables and implementation of behaviour. From an opposite point of view: Since a couple of years my collegues and I implement anything in LabVIEW without classes. Instead we define a typedef and a couple of functions that work on that typedef. As you can tell, a class would be a far better solution to implement such functions as it defines fields (typedef) and methods. You currently have a set of data that is common between server and client, packed into the private field of a class. As you mentioned the MVC before, that would be our Model. I see two ways of implementing that kind of model. First a class which must only define the data and provides no methods (except for accessors). The second option is a plain typedef. We'll settle for the class from here on. Next we want two implementations for the same model (server/client). That is easily archived if we just share the model as we specified above. We don't inherit and just use the class as model which is a parameter for our Controller. So the flow would be: Server Side : Controller -> Model >> [NetworkMessage] >> Model -> Controller : Client Side * Notice that NetworkMessage relates to your entire messaging system. That somewhat 'covers' the data transfer (will make more sense in a moment; maybe less). Next we want the receiver to do something with these information. I'll try to stick as much to your example as possible: The server doesn't know what the client intends to do with the information. So the client must provide some 'meta-data' to the server which is send back in the reply. The client knows how to handle the 'meta-data' in the reply and will act accordingly. (It's the client telling itself what to do with the reply from the server) I also want to get rid of the ridiculous amount of messages the client needs to implement... Basically there should only be a single receiving loop that receives messages from the server and checks if the client implements a method to handle the given data. If that's not the case, it could either throw an error or just ignore the message. Assume we implement a class. That class is for use by the Messaging system and provides the means to transport a Model. Let's call it RelayMessage. The RelayMessage class has two fields, the Model (we need a parent Model!) and a Message (we need a parent Message similar to the Actor Framework). As the RelayMessage is received by the server, it'll do whatever it has to do, insert the Model and send the RelayMessage back to the caller. The caller can than execute whatever is implemented in the Message class. * I hope that makes sense to you... So we need to share a couple of classes between server and client: MessageBase : Is overridden by the client to implement a specific action (Do.vi); The server does not know or care about this! <-- This is actually the decoupling! ModelBase : Defines the base class of a Model which is used by the RelayMessage (as data) RelayMessage : Defines a single Message between server and client (with MessageBase and ModelBase as fields) <Model> : The specific Models which are supported by the server and may or may not be implemented by the clients. Of course the server must know about all Models (not necessarily, but we'll stick to that assumption) If my guessing is somewhat sane, this should give you a more or less decoupled system, where the server knows all Models. The clients implement the necessary models and define their own actions. The missing link right now is how to tell the server what to do... My idea is that the RelayMessage implements a method for each function of the server (we require an implementation of MessageBase for each method, which is put on another field of the RelayMessage). Each method can have parameters and require an implementation of MessageBase from the client (for reply-handling of the client). Now that I think about it, this can even be used to implement a couple of MessageBase classes that are common throughout all systems and allow for the server to issue tasks without request from the clients... Last but not least, if the server should be flexible and scalable in functionality depending on the client (like the client specified what the server has to do), the server could implement a Messaging system where the client implements the functions, which the server executes (so basically the actor framework, but the actor is on the server). Now please don't ask me how to implement all of this... It sounds like fun to me, but also like a lot of work If this post makes no sense, forget it

You should take a look into this: http://lavag.org/files/file/220-messenging/ It is the first thing that got into my mind while reading this topic. Here is some more information about the inner workings: http://lavag.org/topic/17783-continuous-measurement-and-logging-redone-with-“messengingâ€-actors/

On the functions palette go to Express >> Signal Manipulation >> To DDT Place the function and it will show you which data types can be connected to the offending terminal. Change your cluster to an array, connect it to the To DDT function and your VI should be executable.

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.