Neil Pate

I have created some code that is supposed to store a VIs FP.PanelBounds to disk and them restore them later so that window positions are persisted between runs of the executable. Everything works perfectly in the IDE, but in an executable I get strange behaviour. The most common thing that goes wrong is that the window is vertically shifted down by some very noticeable number of pixels, approximately equal to my Windows taskbar (by eyeball measurement). Sometimes it does work though, and it seems to be only on the first load of the executable that the position is set incorrectly. While the exe is running I can close windows and restore them in the correct place (but perhaps then my VI is still in memory or something) I have probed around and the values being persisted to disk and read back are correct, the bug seems to be in the setting of the FP.PanelBounds property. I suspected it could something in Windows (like the restoring animation) interfering with LabVIEW as the window "appears" but I have disabled this and still no difference. Am I doing something silly here? There seem to be lots of different properties for setting window bounds and stuff like this (see https://decibel.ni.com/content/docs/DOC-22385) so perhaps I am doing this a dumb way? I am pretty sure I used this technique on Win XP and LabVIEW 8.6 and it worked perfectly. At the moment using Win 10 and LV2015SP1.

The only thing I can suggest is looking at the Error message which suggests the error arises in Set Lin Log. Looking at your sweep params on the FP, are you sure you have this set up right. You have a start level of 0 A, a finish level of 10 uA, a step of 100 nA and 11 steps. One of those parameters is not correct, as your step level needs to be more like 1 uA to get from 0 --> 10 uA in only 11 steps. Perhaps this is the source of the error? As I mentioned in my previous post, I have not actually used the sweep functions on the instrument. Your time delay seems quite long so would it not be possible to just do the timing manually in a loop?

If you are struggling to get something to work go back to basics and try and create the most simple example you can think of. Can you set a single nA current at all just using the Set Current Level VI that is in the driver? I have used the 6220, and although I cannot remember if I went down to nA (I think I did) I also do configure the range before setting the current level. I see the example does this (it sets the range to 2 nA), which is strange then that you are getting it to work in the uA and mA range. I did not use any of the sweep functions, all my outputs were static so perhaps this is just a limitation of the device (but I doubt it).

But without any kind of re-transmission in the case of errors which is where this whole exercise starts to become tricksy. Caveat emptor...

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.”

The best thing about UDP jokes is that I don't care if you get them or not.

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?

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

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.