hooovahh

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

I think 20%-25% might be over estimating it a bit. 9% XP, 1% Vista, and sure 50% Windows 7, but if they are connected to the internet it should be SP1. But it's hard to say, especially in the test system fields, where older machines are more common than consumer devices, and being isolated from the internet is more common than a consumer PC. Still I consider myself up on the latest updates of NI and LabVIEW and this was the first I'd heard about it. "Not being clear and upfront" is an understatement. BTW that's a neat site.

Sensational title much? It still supports Windows 7 SP1, I've built EXE in LabVIEW 2016 32-bit on Windows 7 SP1 x64 without any issue. I've also built applications in LabVIEW 2015 SP1 32-bit, that have 16.0 dependency drivers, and that builds and deploys to Windows 7 SP1 x64 without any issue. As mentioned in that thread dropping OS support should be made more obvious, but this is really Windows 7 SP0 and older that official support is dropped for.

Okay here's the solution I did that seems to work. You need to make the window the front and focused so that the key presses go into that window. This can be done by setting the Z order. Using this API there is a function called Move Window To Top and you just need to give it the window title name. http://www.ni.com/example/29935/en/ Then I used a this API for sending key presses like Alt and then arrow keys (with delays in between) https://decibel.ni.com/content/docs/DOC-15310

Because the XNode features of LabVIEW require a special license by NI, these properties and methods won't be listed on the XNode, or XNode Library class, but these functions do work. I made a post about this a while ago, and showed how to create these functions in vanilla LabVIEW if you use scripting, or use the QuickDrop function and know the name of the property or method you want. The code I posted also can create a new VI, or place the hidden property or method in your clipboard. I also posted a VI with all the properties and methods that scripting can make which you can use and copy into a VI and use.

Nope, as far as I know there is no way to programatically control this. There are a few private methods that have "Not Implemented" in them and mention Mercury and Merlot branches. This makes me think that at one point NI wanted this functionality, maybe for themselves but since it hasn't be finished in the several years that I've seen this private function I'd guess NI found another way to do what they wanted. If you have the source maybe you could make some hidden controls that VI Server can interact with but the user can't. Like if you have a File >> Exit function, just also have a hidden Exit button that can be invoked which triggers the same code execution. Of course this might be duplicating some of the work you already have. Another option for these menus might be keyboard simulation. If you press Alt+F it opens the File menu, then you could press Down arrow until the desired menu is selected. I've wanted this function off and on for a few years so I've made an idea exchange item here.

Sure thing, sorry I forgot a couple of other details. To enable VI Server access in an EXE you need to add a few lines of text to the built EXE INI file. In your case this is the Executable.ini file in the Executable folder. This INI gets rebuild every time a new build is made, so you will either want to edit this every time, edit it programatically using a Post Build VI, or you can actually specify the INI to use in the application builder settings under Advanced >> Use Custom Configuration File. In this case you can add this text manually just so you can see it working. server.tcp.enabled=True server.tcp.access="+localhost" server.tcp.port=3398 This enables the server, enables it for localhost access, and sets the port to 3398. This can be any number but needs to be unique. Then in the Open Application Reference you specify the port as 3398, and the machine as localhost. Once you have done this, run the EXE, run your VI, and you should be able to do things like list the Exported VIs, open references to those VIs, and get references to the controls on the front panel. Attached is a snippet back saved to 2014 that will read the Boolean Indicator value.

Will the steps mentioned also force LabVIEW to recognize the SO file as a dependency, and include it any builds? That's one issue I thought I remember having with Windows built EXE, when specifying the DLL path by the CLN input.

If you are using VIPM this is already done for you. To be able to install a package means that the VI Server business is already working. As for how to know what port is what version of LabVIEW, you can look at the LabVIEW.ini to see what port goes to which, and you can read the Windows registry to find what versions of LabVIEW are installed, and the path to the LabVIEW.exe and LabVIEW.ini files. This is all done in the source of the LabVIEW Tray Launcher I linked to earlier. Glad you were able to find a solution.

I literally shaved the day before. I can grow a mean beard, but I don't travel with any trimming equipment. So I shave on Sunday, and by Friday I'm looking pretty rough, and it's not just from all the Shiner Bocks. Also does everyone think they look dorky in pictures or is it just me?

The command line option only works if you know no other versions of LabVIEW are currently open. LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version. If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with. Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue. The work around is using the technique I've mentioned. But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.