ShaunR

Pretty much everything in this Toolkit I don't know how they will implement it on Mac and Linux, although similar capabilities would be nice.

I have a solution. It works. It even worked when the force destroy was just reserved for future use in 2009 (although you still seem to be missing the leaking point). As I said previously. We didn't used to have to worry about memory management until queues et. al were introduced - which is where we started with this little rabbit hole..

Sure. Obtain returns the actual queue reference rather than a copy.

You see? That's why this is such a problem for people. Re-entrancy is meant for non-blocking parallel execution. Using it as a memory storage method is just an abuse of its apparent behaviour. I think people looked at LV2 style globals and thought they would be clever and use re-entrant VIs ina similar way. There is one huge difference with a LV2 global though. It is a singleton! When I use re-entrancy it is because I want things to be non-blocking. I use storage methods for memory storage like the class private data which was intended for that. That doesn't help the OP, though since it is a NI toolkit that has this so the only sane recourse is to not set class method to re-entrant and put a huge note in the method diagram of why. It is exactly the same as malloc for memory leaks. Obtaining a queue reference creates a copy of the ref so the programmer is forced to reference count and twin each obtain with a release.Keep obtaining and miss one release and you will run out of memory eventually. This was such a problem wherever I went to work, I created the Queue action engine that encapsulates the queue primitives to ensure there is only ever a maximum of 1 reference. Download any of my software and you will see it where queues are used. Amen. But I would argue they are not exceptions. The maxim is "never use re-entrant memory storage" and all those you describe are not re-entrant (well, FPGA might be-I don't really know what you are referring to there). I wouldn't go as far as say "never store state in a VI" otherwise you are back to global and local variables and those you list were invented to address the issues with those memory storage methods.

Not so. Memory leaks were introduced with the queue, notifier etc primitives. Before then there was no way to leak memory programmatically, only allocate huge amounts to get the bulldozer. The thread safety issue was introduced with pooling of re-entrant VIs. Prior to that there was only pre-allocation re-entrancy and no you don't get similar issues with pre-allocated since it is lack of control over thread execution order of an instance that causes the issue which is non existent with pre-allocated.To replicate in classical LabVIEW you have to call a pre-allocated, re-entrant from a shared clones VI. If you wan to go back further, there was only a single virtual context so you could have executables share global variables

That may be true as a "work-around" but having local variable storage like this, in a class, is an anti-pattern to begin with. It is the equivalent of declaring a static var in an accessor. The issue here is thread safety and that method of local storage is not thread safe. There used to be a time when LabVIEW programmers didn't have to worry about memory leaks and thread safety-that was an "other languages" affliction.[queue wavy, flashback sequence]

NI have a selection guide for Ethercat and lists PXI as requiring additional hardware. That is before getting to propriety protocols. I would highly recommend talking to you local NI rep. They will be able to give you definitive answers and may even allow you to use a card for a short period to see if it is suitable for your needs.

He is referring to the LabVIEW splash screen where it says the version number in the bottom left hand corner. It says things like Initialising Resource Files, Initialising Plugins and at one point, Converting Toolkits. OP: Do you have Norton Antivirus?

Why is that?

Ooooh, that's a bit sexy-have a like! I think you have just given me have a brain-wave (maybe a brain-fart, difficult to tell at the moment) I've been thinking a bit about the SQLite API for LabVIEW recently because it has been pretty much feature complete for a while now and no-one is requesting any new features and either there are no bugs or no-one is telling me. Your post to that software has given me the embryo of an idea of a possible improvement to the library. It can already export data to CSV and SQL, mainly for archiving purposes, but what about PDF (or HTML for that matter) for report generation?. I think it might be nice to be able to generate reports directly from a DB and squirt them out to, say, PDF. I'll have to have a think on this.Thanks for pointing out that software.

Pretty much yes (there are a few other missing too ). Of course JKI could ask their lawyers what they think Just to clarify. BSD is a copy left distribution licence. So, for example, CR components that use them don't need to reproduce the copyrights because VIPM will go and get any dependencies separately. When an end user uses the CR code in their software, then they do have to include the salutation and that is not always clear to some. As for removing attributions. I am against that and I would be against it even if I hadn't supplied one insignificant piece of code. I have other code where I am not required to attribute but do anyway as a mark of respect for those on whose shoulders I stand. It acknowledges the community spirit, effort, hard-work and altruism of the contributors and can be used by less well known programmers to showcase their skills. ("I have had code published in the OpenG toolkit" is a pretty good brownie point in a job interview, is it not?). I fail to comprehend the (mainly companies) that think because something is free in terms of fiat tokens, the contributors time is of no value and is therefore contemptuous and shouldn't be acknowledged.

Yes you are right.

TIL: Mung is a real word created in 1958 and not a made up word we used to use at my school.

Nobody moved the relevent posts across, so I'll have to cut and paste bits here instead instead of quote the originals. Hmm. Composition Vs Inheritance. I'm half tempted to show you an example without classes at all just to show that using lists has nothing to do with inheritance. As for composition. I though you were proffering the Composite Pattern. When you talk of composition, I think of [object] composition like the image below which is a form of inheritance IMO We are already foundering on terminology so it is no wonder people have a tough time with OOP. Nothing to do with discussion. It is the name of a criticism of OOP that what methods and properties that an object should consist of, is subjective and based on the viewpoint of the programmer. If you haven't had or seen that argument; I would be very surprised.The relevance is implicit. The Composite pattern yields a "Bottom up design". The Lists are a "Top Down design" these are supersets to design patterns in any paradigm. You are looking at the system and saying "what pattern can I apply"?. I am looking at just the test management and whats the best way to solve this bit. (oh how I wish we could inherit from TreeView) So this is a "what if" scenario that doesn't really pose an issue for lists, but is the type of thing the pattern was designed for. I'm not even sure I understand "interface bloat" in terms of a LabVIEW implementation since I either use the TList Vis or use the "Frame" VIs which at this pint probably only has one or two VIs (Get Result and Execute?). Each child is also free to handle its own "aggregation" however it sees fit. You can also have "several different flavours of collections (lists)" as well as Steps, Actions and any other classes you care to include but the main thing we want to do is move them around within the list, change their order and add and remove them so it;s hardly bloat if we are actually using those functions. I consider a collection to be the same as a list, so your first sentence doesn't make a lot of sense. But no. In LabVIEW you don't have the exposed methods unless you override explicitly so I'm not going to create a VI in the child for every VI in the base jsut to give me the right coloured squares. I will just use the base class VIs. Granted in C#, Delphi et.al your code completion list will be shorter so you can reduce "interface bloat", but they get those automatically without writing skeleton functions. We don't have that in LabVIEW so interface bloat is moot as far as I'm concerned. The downsides I see is that it really doesn't give you much and it kind of fixes you into an application architecture that may not be that good for other aspects. For Sequences and Steps (slipped back into TS terminology as we don;t really know what a Frame is) they are just line items in a list. It is "actions" that actually do stuff and everything else is just ordering the actions. All you really need is a list and execute to manage sequences, steps and actions. What you actually execute is a different matter.

I think the takeaway is that people would like a single licence that covers all the VIs in the OpenG that they can then reference in their documentation. A BSD, Creative Commons or custom licence with a salutation section listing of all the contributors that can be cut and past into an appendix or included with distribution that fulfills all licencing requirements. Something where the developer can say "put that in the manual" and sleep safe in the knowledge no vampire will attach itself to the financial jugular.

It is? Wow. News to me Perhaps a moderator can move each of our last two posts here?

I don't use any OpenG so its not installed.

I think it does,

I never said that I was using a pattern of any kind. All I am doing is using common denominator implementation for a very specific part of the problem. Frames and steps are both lists and either can contain any object type; it is just a semantic difference. I know what you are getting at, though. This is a good example of the tradesmans viewpoint dilemma or if you go back a few years the very similar Bottom Up Vs Top down design argument. I have stated on previous occasions that I use both in every project (diamond design) I suggest we get into that on a new thread if you want to explore it further as it could go on quite a bit.

I do. Particularly for string manipulation (regex, scan from string etc) where an error is too disruptive. One of my pet peeves, though, is the read from file VIs They give an error 4 when you request more bytes than are left in the file.This has prompted a few of us to create a "filter" vi to reset error 4 which should be a warning at most, IMO.

If you tell me what the troubles are (support thread), I will probably be able to figure it out for you

Manually add the .lvproj file to the project (i.e. itself) then it will appear in the build source distribution.

I say liken [sic] you say litchen [sic] lets call the whole thing moss.

Increase your 100 ms timeouts (and your 10ms listen) to 1 sec. Also. Try the Transport examples and see if you get the same problem.