Neil Pate

I gave quite serious thought to whether I should post or not as I did not really want to derail the thread. However, that joke is perhaps in my top two of tech jokes I know, it is too good to not share.

The other one is..

“Whenever faced with a problem, some people say `Lets use AWK.' 
  Now, they have two problems.”

I regularly use the "Explore" option from a build spec, it normally works as expected.

Just yesterday LV2015 SP1 would take me to a different build spec folder when I did this. Very strange indeed. 

Sorry, I will check out the community page and keep my comments there.

(sometimes I get my tone wrong after being handed two babies at 6 AM)

Thread hijack!

DCAF, (de-caf, right?). Looks interesting, but am a bit put off by the code smells in this screenshot...

Last year I tinkered with one of the Linux based cDAQ systems, and yes it supported a GUI. I did not try any kind of events, just wanted to show the FP of the RT code for info purposes. Some strange things happened though, some of the indicators just would not update even though they were being fed data in the same loop as others which were working.

I had no real use-case for the GUI, it was more out of curiosity, so I left it there.

Sure I know about the CTRL-drag trick, I use it all the time. The problem is I use locals seldom, so most of the time there isn't another one to clone nearby on the BD.

I use locals sparingly, but in my typical use case where I really just need to use a value in more than one place (lazy yes, but not worth the effort to do it any other way) I need to read from a local rather than write to it. The default condition is to write though, so I need to change my virtually every time I need to use one. 

Am I the odd one out here?

Don't suppose there is some SuperSpecialIniKeyForDefaultLocalVariableDirection?

10 hours ago, shoneill said:

•   If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

 

Did not know about this workaround. Thanks!

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? :-)

1 hour ago, Manudelavega said:

So the leak would come from the variant stored in the shift register?

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.

On 6/21/2016 at 4:54 PM, ShaunR said:

If you right-click on the icon for setting the volume and select "Select Type>>Array"; you can enter more than one value.

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.

1 hour ago, Stobber said:

No, I don't have documentation. I learned about it when I worked at NI as a Systems Engineer and had access to unpublished documents about LV, as well as people who had developed the language. I verified it with an NI R&D engineer while developing a project in March of this year

That is good enough for me. 

2 hours ago, Stobber said:

The magic pattern is when you use unbundle by name on the same items, in the exact same order, in a path of unconditional logic (i.e. bundle node not in a case structure). If you change the order, or fail to bundle an item, or bundle an extra item, or put the bundle in a case structure the compiler will duplicate the entire cluster in order to finish the operation. If you follow the pattern, it'll update the items in-place.

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.

On 5/15/2016 at 10:33 PM, drjdpowell said:

Why?  Actors are tools.  One configures a tool for a specific task.   You know the task; the tool doesn’t.  Why would the tool be responsible for configuring itself?

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