LogMAN

Tested it and it does not work (VIPM 2014). Also tried to created my own package, changed the description manually and got the same result: Might have something to do with the Community Edition though, I'm pretty sure this was possible at work where I got the Professional Edition. Edit: Could not hold myself back and activated the Pro Edition - The issue is gone! So, your problem is only with the Community Edition.

Wild guess: LabVIEW uses the "Delete From Array" function in case 0 to dispose of used elements as soon as possible. For cases 1 and 2 it uses "Index Array", thus does not free the memory (the original array is just passed to the output tunnel and freed afterwards in one go). Case 3 is less efficient as the final 2D-Array takes time to build (requires re-allocation in memory in worse case). Maybe ask NI support? Oh wait...

I have made the same experience in the past, tried many things and finally moved the examples folder under LabVIEW sources for a couple of reasons: The example folder contains LabVIEW VIs only (in my case that is), so it makes sense to put them under LabVIEW sources. API sources can be arranged differently than "regular" projects, if there are good reasons for it. However this should be made standard for all APIs! Depending on how many configurations you have to manage (about 20 with regular changes in my case), it is less painful to just accept the standard behavior, than trying to convince VIPM to do otherwise. Or more accurately: You can do this with VIPM, but it is a pain to do for every single package, let alone multiple projects! Re-writing the *.vipb requires you to do it every single time, which you will eventually forget! You could potentially use the VIPM API, if you REALLY want to do things your way (never used it though)

They do exist in files created with VIPM 2014 and they work the same (just checked and got the same changes) "ID" and "GUID" are both GUIDs, so unless they are calculated based on the configuration data (which makes absolutely no sense), they are just unique identifiers (at least in VIPM 2014). There might be other changes involved, like comparison of the Modified_Date with the actual file date, but there is no chance to know for certain unless JKI tells us. So in my opinion this is a bug (even though we are technically not supposed to change the files manually). Most changes are of cosmetic nature, the others are only relevant to a very small amount of users. So unless there is a great new feature or a fix to a critical bug, there is no reason to upgrade imo.

SourceForge is to my knowledge still the host for all OpenG packages: https://sourceforge.net/projects/opengtoolkit/files/

The palettes are auto-generated based on the source directory defined in the Build Information tab. I suppose it is set to <ProjectRoot>, so change it to <ProjectRoot>/Source/LabVIEW and the palettes should be correct.

It has not been mentioned in the release notes, but "things" change all the times I have yet to install and test the new version (no need, because if it isn't broken don't fix it...), however I would like to suggest a way for you to check it yourself: Keep the original file and change one character in your description in VIPM, then compare the two files. If there is a checksum there will be an obvious change in one line. If that's not the case you might have broken the package by saving the file in the wrong encoding (UTF-16 instead of UTF-8). Maybe try another editor (Notepad++ is what I work with mostly).

What is your issue? Put COMPorts_EnumCleaner.vi onto your block diagram and you are ready to go. In all cases you need Administrator privileges. If you want to run the code from within LabVIEW (by running the VI), you'll have to start LabVIEW as Administrator too.

Run the program as Administrator.

You can execute any SQL query using the Execute Query VI from the Advanced palette. Here is an example I just put together (untested of course):

I don't have experience with MySQL specifically, but it should work similarly to MSSQL on this behalf. Check these two sources: http://www.w3schools.com/sql/func_date_format.asp https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-format Your query should be something like this: SELECT DATE_FORMAT(column, "%Y-%m-%d %H:%i:%s") FROM table_name; Use the Scan From String function to convert the string into a LabVIEW time stamp:

As far as I know there is only one library freely available at NI labs: https://decibel.ni.com/content/docs/DOC-30140 You'll of course not receive any support from NI, but it is a good start. I have never used it btw.

The DVR will remain valid for as long as your dynamically launched VI is running (or rather for as long as the VI which created the DVR stays in memory). Since you wait for it to finish execution LabVIEW recognizes the VI as being idle and therefore removes any remaining references automatically. Reading the indicator value as variant doesn't help either, as LabVIEW cannot recognize the value as reference type. You can try an FGV to store the DVR in a buffer (the FGV must create the DVR though), but this will work for one instance only. Another option is to create the DVR in the caller and pass it to the dynamically launched VI. That's assuming the caller knows the DVR type => maybe use a subVI to create the DVR in the caller and pass it to the dynamically launched VI.

Do you use an USB-Serial converter? They have become less and less reliable the past few years in my experience (might depend on the chip though). Try a PCI card or the on-board port.

Check my last VI above. The terminal is set to 2 => Always include commented out diagrams

No. I just checked with a dummy project. Any code within unreachable cases is ignored. It doesn't matter if it's directly in the main VI, an inline VI, or a normal sub-VI. You can use Booleans, Numerics or whatever you like. Put code in an unreachable case and it is not listed by Get VI Dependencies. Maybe I should file a CAR and see what NI thinks. In my opinion the dependencies should either be listed, or the VI should break.

Okay, finally found a minute to do this. Here is the same VI but this time with a legit invoke node that doesn't require internet magic: I find the execution speed slower by a huge magnitude (minutes vs. seconds). That's obviously because everything is being loaded into memory. It can be made faster by unchecking some of the options though. Anyways, this VI returns even more Orphans than the original one which it really shouldn't (it recognizes VIs in conditional disables which the old one didn't). That was very confusing until I found the reason for it: "Get VI Dependencies" will ignore code that is inside a case structure with a constant wired to it (at least if that's the case in the top-level VI). Don't know if this is intended, but that's how it works.

By the sounds of it your solution is more solid and works with more complex projects, which is very nice. I'll play around with that node for a bit, might prove useful for future cleanups... Actually the "Linker.Read Info From File" reminded me of how the VIPM generates packages. VIPM has the same issues regarding conditional disables, so I think it uses the same mechanism.

Hello everyone, I want to share a VI that I recently created to search for orphan files in a (very! ) messy project. As it turned out it's actually very easy to do that (if you find super-secret stuff on the net): This VI will find files (VIs, Controls, Classes, etc...) in your project folder that are not linked by a given top-level VI. This is done by comparing the call-chain of the top-level VI with the files on disk. It assumes your files are in folders relative to the specified root directory. This also means that files outside the hierarchy will be ignored (vi.lib and such). Be aware of (at least) two things: This VI will return false friends if you happen to have any "Open VI Reference" call with constant VI names or paths connected to it (not a problem if you use static VI references). VIs in diagram disable structures are not listed in the call-chain. So if you use conditional (or regular) disable structures this VI will return false friends. Does anyone know a solution to number 2. actually? Hope this proves useful to you too.

Way better Still you perform many write operations by executing the SQL in a loop without a transaction. The more values you have, the slower your loop becomes. Your current implementation might result in incomplete data in case of SQL errors (you can't undo your actions)! Try to add a transaction around your loop (It's very easy to do, costs nothing and is at least worth a try): Transactions will prevent file-writes for as long as they are not committed (this is why it might save you some more time). By calling the Commit VI at the end, all data will be written in one go. In case of errors you can just reverse everything by doing a rollback (The Commit VI will do a rollback on error automatically).

Use a prepared statement and a transaction. Your current implementation requires writing for each iteration which is slow obviously. Check out the "Insert many rows code template" on the SQLite Library >> Code Templates palette. The prepared statement will allow you to use binding which is very useful as it maintains data types in your application. See following Picture for an example (I can't test it right now, but it should work like that):

LAVA used to float the marked answers on top of everything. It's just that hardly anyone marked a post as answer. Maybe it was not obvious enough how to do it, or the nature of the topic did not allow for a single post to be THE answer.

The VI does exactly what jj321 said it does, access the control of a clone VI. I think the reason why nobody is answering is because there is no question, just someone sharing news with everyone Here is the snippet of the VI: I don't know why anybody would want to access the controls of a clone VI like that since you would normally pass data while calling it. On the other hand if you need access to information from the VI there are other ways like notifier or queues. I have used a similar approach to call LabVIEW applications via ActiveX and sending information between the caller and the executable, but never from within LabVIEW... @jj321 would you care to explain the use-case of your VI?

What package are you talking about?

Now that's a very good point. I didn't notice until now and I like it very much! Because we missed said feature?