hooovahh

Using the Variant to data, turn it into an array of variants. If it returns no error, then your input is either an array, or a cluster. This trick can also turn a cluster into an array of variants so you'll need to check for that too. Maybe check to see that all the data types of the output are the same? But even that isn't a guarantee. How did you end up with an array that thinks it is a variant? Maybe there is an unnecessary To Variant in there some where.

I used JSON with the WebServices calls. Most projects don't use them, but the ones that do use JSON as the results type, and parsing using the NI primitive works the majority of the time, but then there are unsupported data types, and odd timestamp support.

So this is an edge case for sure. But there are times that I want to put reuse code on the palette, and drop a VIT on the selected VI. VITs aren't very common but they will (normally) force the user to save the dropped VI as a new VI. It is like opening a template from your File >> New... menu. It doesn't drop the actual template, but instead makes a new unsaved VI, that has the code of the template in it. But if you drop a VIT from your palette you don't get a new copy, you get the template itself. This came up in conversation at Becky's presentation on the Project Templates at NI Week this year. I suggested that an XNode could make this possible and so here it is. (sorry Becky for taking so long I forgot about it) Anyway if you drop this XNode from the file explorer or palette, it will drop a new copy of a template, then delete the XNode that was dropped. If you want to use your own template, edit the Get Help VI description, icon, and Window Title (this is what is shown on the context help and palette). Update the code in the Template.vit, edit the VI description, and icon of this file to be the same as the Get Help VI (this is what it looks like when dropped). The only issue I've found is that if you drop the template from your palette you need to use undo twice to get rid of it. Once to get rid of the template (but this brings the empty XNode back) and again to get rid of the XNode. Drop VIT Xnode.zip

An LLB is not a library. An LLB is more like a flat zip than anything else, and name space does not get modified. Your example of Init is a perfect one where libraries from all kinds of sources use the same Init, Configure, Read, Write, Close etc functions. Editing hardware drivers in your project is no problem, but editing ones in vi.lib, or inst.lib can cause more issues due to the distribution method. Update a package, and all the changes you made went away. If you organize via directories, then this is also a reason to consider the newer file structure since then your EXEs will have the same folder structure you have on disk, and doing a function like reading a VIs file path (given a reference) will tell you where on disk that VI came from. This can be useful when logging errors because you can log the full path to the VI that generated the error. Or the relative path from the EXE to where the VI is in the EXE. In the end it is of course up to you but I've found the new structure very helpful over the years. Yeah you need to know that a single strip path won't bring you to your EXE, but I use the OpenG function that is Current VI's Parent Directory which will keep stripping the path until a directory is found which works in both the 8.x and newer structure. You should get one of those super huge floppies, I hear they store 2.8MB.

So do you still use the 8.x layout on all applications built? I haven't used the 8.x layout since 8.6, and yes I do believe the only real benefit comes from when you have two VIs with the same name in different libraries, it isn't necessarily a LVOOP thing. There maybe other benefits that NI has made into compiler optimizations that maybe only effect newer layouts, but only NI could say for sure. I may have a library that reads an analog signal on one piece of hardware and so to organize it I name the VI Hardware X.lvlib:Read Analog.vi I can then have another library with another name Hardware Y.lvlib:Read Analog.vi Having two VIs named Hardware X.lvlib:Read Hardware X Analog.vi and Hardware Y.lvlib:Read Hardware Y Analog.vi seems unnecessary when the library name already states what hardware it is for . As you are probably aware the flat layout of 8.x means they can't be in the same folder so more folders are made to fix this, where in the newer layout folders exist and so these VIs can reside in the EXE with the same folder structure as on disk.

This thread is 7 years old, and predates several LAVA database issues and data loss. I wouldn't expect to be able to find the original attachment, and those involved in this thread likely don't have a copy of the files.

I've used the Variant Probe as a probe (in the development environment) but also used it on the front panel of a VI, and in a VI that is built into an EXE without any issues. I used it in debugging messaging data between parallel actors in the EXE, so I could see a history of the messages that were send and received, and the data in the messages. It wasn't used too often, but made it possible to get an understanding of what the individual actors were sending, and thereby what they were doing without a full development environment.

I try to never miss out on an opportunity to toot Ton's horn when it comes to that XControl. Yes as already mentioned the Variant Repository that is available for download here is a VIPC, which contains the Variant Repository, and the Variant Probe. I included it because I felt that XControl really is a simple way to view variant data and it's structure, which is why it was included as an example showing how Variant Repositories work. When I give my XNode presentation, I start by explaining how they are related to XControls, and I use the Variant Probe as the example XControl. It's a perfect XControl, it's use cases are relatively small, you don't have lots of weird user interactions to worry about, and it displays data in a way on the UI that is more clear than any other native control. But do be aware that there is a bug with the Variant Probe, and updating it often in a loop will cause a very slow memory leak which will cause LabVIEW to take a longer than expected time to close. I reported the bug here but no new package has been made, so I just posted an update with the fix in the package.

I just realized this bug still exists and no update has been made. So for others that might be interested in using this with this fix applied, I made the fix and rebuilt the package. The spec has the version limited to >=2011 but I can't honestly remember what version I saved the VIs in and I only have 2015 installed at the moment. Variant_Probe-2.4.2-0.ogp

Through scripting? Looking at the available classes I think your only option is going to be to save a VI somewhere that has the register event callbacks configured the way you want, then programatically copy and paste them in. The reason I suggest this is because the Register Event Callback node appears as to be in the GrowableFunction class, and that has no methods (private or public) that can set the method of it. So the only solution I can think of is to make a VI that you'll use as a template, and it can have all the nodes configured the way you want and just sitting on the BD.

We have some 3rd party software that generates Access databases. For those I use NI's database connectivity toolkit. It was the first I tried, it was free (or included) and it worked. But for new database my software creates, I generate them and read them using SQLite and your toolkit. We don't do much database work, and it has always been decentralized.

You can still perform a Find All Instances of a particular VI, which is probably more useful because you will only find the VI for a particular method call of a FGV, instead of finding every instance. I believe what you are asking is if you can search for the polymorphic VI, to which I believe the answer is no, you can only search for members of the polymorphic VI, which in this case would be a particular method.

Yes this was already posted in LAVA over here in the LabVIEW >> General section, but to be honest I think this is more appropriate in the Lounge so I'll leave this here rather than merging it.

Yeah I like this idea and made a (half complete) tool for generating these polymorphic VIs from FGV, posted over here.

So here is the VI I've been using, I can't remember where I got it from but I believe it was on NI's community page. The account I've been using has the less secure apps enabled and that's it. It is using port 587. Is it a network issue on your end? Does it work from another network like at home? Email Using Gmail.vi

Sure, there's a couple of options but I think what can be done is to on startup, get all control references, then find which ones are type defs, and then get the path to those type defs, and if the path is what you expect, to register for those control references. Attached is a demo. Find Type Def Demo.zip

I was always cautious when using the aggregate compare mode because I didn't fully understand what it meant. Reading through the documentation it seems it should work the way you described.

Does it behave this way on other computers? Maybe resetting MAX config? Not quite sure really but if you tried another piece of hardware and it behaves the same it would make me think it is not the hardware, but some software or config on that PC. What kind of scale is used? Is it a linear, table, mapped range, etc? I guess it probably doesn't matter but I'd try to see if I can make any scale work on the full range.

A quick google search shows several tools for removing passwords from zips. No idea if these actually work. Alternatively there are tools like this one which appear to brute force the password for you. http://www.isunshare.com/blog/how-to-remove-password-from-zip-file/

"This contract engineer discovered the secret to LabVIEW programming, and NI is furious."

To answer the primary question of the thread, yes I do still use them but kinda rarely. For each medium to large sized project I'd say I probably create 2, and there are probably another 3 or 4 buried in reuse library function, used in the project. The reuse functions I can make a decent argument to make them classes, for the project specific ones, I could say the simplicity, and ease of use for other developers makes me want to leave them alone. In most of my cases I don't see action engines working well because there maybe a time when I intend on doing some kind of periodic function, like checking status and reporting it every 100ms, and an action engine is a blocking, synchronous call. So I usually end up making a separate asynchronous module (actor) so that in the future if I need to do some task periodically it can be done there. The calls to this will still look like the action engine, but with a message to the actor, and then a message that is in the reply coming back so the call will still be synchronous, but asynchronous tasks can take place too. It's rare that I can convince myself that an interaction with some private data, will never need this feature.

Yup totally agree. Array stuff needs to be evaluated. Many improvements could be made from inlining, to the new conditional, and concatenating terminals in 2012. Several things could be removed from the palette too to use the native functions if they have replacing functionality. Things like Strip File Extension exist on the File I/O palette, but don't quite cover all of the same functions. Same with some functions on the LabVIEW Data palette, and the newer variant palette.

The LabVIEW compiler is smart, and it knows that if you are doing some operation that doesn't use the outputs (and a few other key determinators) then it won't even execute the code at all. Your case 11 isn't actually being executed. This is dead code elimination and constant folding. Updating controls is an asynchronous process, and adds a lot of jitter to measuring timing like this. That's one reason why you'll notice my code doesn't update any of the controls until after all timing values have been taken. To get a more accurate measurement you should not update or read from any control terminals inside the sequence structure. I highly recommend watching some of these NI Week videos from this last NI Week where Ed and Christian talk about performance measuring and benchmarking. https://decibel.ni.com/content/docs/DOC-48493

You are a braver man than I. I wouldn't go through the registration, I'd be concerned NI was going to charge me for an event that took place in the past. Thanks for being your guinea pig.

Because you're doing all the operations in parallel, this is a poor test and should be only doing one thing at a time. Also you should disable debugging, and automatic error handling. I also think your time is too small to measure well enough. Maybe try a larger sample size. Here is a speed test I did on the writing of the new IPE and it shows improvements. https://forums.ni.com/t5/LabVIEW/Correct-way-of-using-the-Variant-Get-Replace-In-Place-Element/m-p/3334502#M978560