Neil Pate

So of course my first attempt to create a simplified version has failed spectacularly. Rock-solid memory usage... drat. Perhaps it has something to do with arrays embedded in the inner clusters.

A most excellent description of the sometimes arcane Front Panel dimensions can be found here. All credit belongs with the original author, David Staab. I put this here so I can find it easier next time I need it, which seems to happen every couple of years or so :-)

Password? :-)

Something like that. If I get a chance I will see if I can create a minimum code proof of this bug so that it can be analysed further.

Interestingly, this slight modification does not appear to have any leak. LabVIEW bug?

I am currently working on a project, one component of which is a OPC-UA interface to a PLC. There are approximately 100 nodes (variables). Part of my work has been to keep in mind the next iteration of the architecture needs to be able to handle approximately an order of magnitude more nodes. Dealing with this many "variables" in LabVIEW can be painful unless some programattic techniques can be used. For debugging it is useful to see all the node values, and so I implemented the technique shown below where the name of the variable can be used to update a cluster (nested to a maximum of two levels deep). This works well. The green VIs are the OpenG Cluster access VIs. However I have virtually conclusively proven to myself that when this is built into an executable this portion of code shown below exhibits a memory leak of several kB per second. Interestingly, I use a more simple version of this technique in another portion of the project to update some GUI elements, and there is no noticeable leak. Has anybody seen this behaviour before? I have not poked too far inside the OpenG VIs, but from what I have seen they should not leak anything.

Update: this is caused by including the Get Build Specification Version VI (\vi.lib\AppBuilder\AB_API_Simple\Get Build Specification Version (path).vi) For various reasons I needed to know the current build number, and found that VI to do it. Unfortunately this causes a bunch of extra dependencies to appear in the project and the necessity of this mxLvProvider.mxx in the built application, so for me is not a pleasant solution.

The selector terminal on a polymorphic VI does not really take space away from anything else, who wires that close to the bottom? I get your point though.

Nice to know. I hate settings that are tucked away in menu options like that. Such little discoverability for somebody trying to grok the API. Wonder why the polymorphic selector is not visible? Just checked and by default if the VI is dropped from the palette it is hidden.

Does anybody know why my application executable all of a sudden needs the file "mxLvProvider.mxx" to be in the data directory? The application builder puts it there automatically, but I do not know what it is for. If I remove it my application does not run, instead the usual file prompt dialogue pops up when I run the application. Also, can anybody shed any light on what this file is for? My PC seems to think it is a "MAX Configuration UI" but that does not make any sense either. Crossposted here.

That is good enough for me.

Interesting, do you have any official documentation to back this up? Not that I don't believe you, I am just super curious about optimizations the compiler can make, and things that can be done to help. For example see this discussion about using the Swap Values prim.

Sorry no, I have not tried the .NET interface. I suspect MS will have lots of angry customers if they truly decide to remove (rather than just deprecate) the ActiveX interface. I am going to leave it to NI to solve that problem if it arises,

Strange, I have Excel 2016 and my Report Generation Toolkit code still works just fine, with its usual ActiveX implementation underneath.

Whatever the reason, since the upgrade I visit lavag.org far less regularly on my phone, which is a pity.

You are right. I am overthinking this, I will keep my System Config action engine and just extend it a bit.

So my current framework is very "actor" based (home-rolled solution, yup "yet another actor framework"), but one thing my actors do not do is take care of the serialising of their own configuration information, instead this is handled by the System Config action engine. Now I think perhaps each actor should be responsible for the serialisation of its own config. However this could lead to trouble if they are all trying to write to the same file on disk at the same time, so I guess each actor needs its own config (ini type) file or other solution (a DB as proposed, which I am not that keen on as I am very much a fan of human readable config files). My plan was to extend my config action engine to include a user event for data change, and try and remove the global access out of each actor so that my actors (just a class), store the config in their own private data. I definitely do not want a message per parameter though, just a single event saying "config changed" but then I think this leads to more pain as the user event would either need to include the entire system configuration as its data, or I need to have an event per parameter? hmmmm...

Yeah, when I say process I do not really mean OS process, rather "free-running loop within the LabVIEW application context". I have messaging for a bunch of other stuff in my framework, just never got around to doing this for config type information.

I am wondering how others implement the sharing of configuration information between processes. For example, I have a camera with an acquisition time specified by a user. This value is editable by the user during run-time and persisted to disk so next time the application starts it is used. The process doing the image acquisition is free-running, and the GUI doing the editing of this parameter is in another process. The technique I use to solve this is a bit old and rusty, namely an LV2 (actually Action Engine) with all the system config in it with methods to read and write from/to disk as well as set accessors for each of the variables. The acquisition actor just reads out the value as it needs it, but does not actually store it internally in its own process. I currently have no mechanism in my framework for informing a process that a configuration value has changed. This works fine, but I wonder if others have gone the extra step and implemented configuration data using User Events and removing the global data store? In an actual system there will likely be significantly more configuration parameters.

Indeed, I have been getting this error on my phone for a month or so now.

Nice, what did you plot this with? Not the 2D Picture control I am guessing

I read the node names from a file on disk, along with a description of their data type. This I use to set up the server, see attached. Note: I don't really have much OPC-UA experience, so cannot say if this is good or bad practice as I have done it. It works fine for my purposes though. The other frames of the case structure deal with the other possibilities, like Folder.Item etc

Ditto for me, I would be very sad if this place shut its doors. I think the audience here is very different to ni.com forums, and personally I do not like the community aspect there, it feels too distributed. If I have questions, which I still quite regularly do, this is where I am going to ask them. Put another way, lavag.org is one of the few sites I would gladly pay towards the cost of running, so thanks for everything Michael :-)

I still must be doing something stupid, how do I actually made modifications to an existing (or a copy of) XNode? I can open the ability VIs fine, but they are locked. All I want to do is try and modify your XNode to make it accept a DVR to a variant rather than a plain variant. This is my first real foray into XNodes, so I am probably missing something obvious even though I have tried to read as much of the literature as I can.

So anybody want to give me a license to edit these xnodes?