LogMAN

3 hours ago, JKSH said:

Could someone kindly try the attached *.vipb file and see if it opens?

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.

4 hours ago, Rüdiger said:

I have been sent here by NI Support

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)

4 hours ago, JKSH said:

• The "Modified_Date" attribute in the top-level "VI_Package_Builder_Settings" tag
• The "ID" attribute in the top-level "VI_Package_Builder_Settings" tag
• Every single "GUID" value under the "Functions_Palette_Data" tags.

I'm pretty sure these fields existed in the previous version of VIPM too..,

They do exist in files created with VIPM 2014 and they work the same (just checked and got the same changes)

5 hours ago, JKSH said:

but perhaps they've been given a new role. (If so, why???)

 "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).

5 hours ago, JKSH said:

Perhaps I should uninstall the latest version and go back to the previous...

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.

12 minutes ago, hooovahh said:

Thanks for the link Shaun that is a handy thing to have, but the only OpenG package listed is the 2Kb package, telling VIPM to go download and install all the dependent packages from the internet.  So that package without the internet is useless, not sure where all the actual OpenG packages are hosted.

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.

2 hours ago, JKSH said:

Hi Jim,

I just tried editing the XML on a VIPB file, but VIPM 2016 complained, "VI Package Builder was unable to open the build spec due to an error." Even changing a single letter in the product summary/description triggers this.

Has some kind of checksum system been implemented in VIPM 2016? Is there a way to continue making manual edits on VIPB files?

Thanks!

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

3 minutes ago, Mustafa Acar said:

Actually, I want use in my VI . How can I do it ?

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.

2 hours ago, Mustafa Acar said:

Hi, 

           Thank you, for project but I have a problem. When ı run your program. This error appear. 

"Possible reason(s):

LabVIEW:  Remote registry access denied."

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:

7 hours ago, Meriem Ait said:

Please how can i have the modbus library for labview 

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.

31 minutes ago, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

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.

21 hours ago, josborne01 said:

Hi ErikTheRed,

I am having this EXACT same problem!

My code runs fine for a very long time.  Then intermittently produces that "unknown system error" when I check the number of Bytes at Port. 

My code looks really similar to yours.  I establish a serial connection, and then sit in a loop checking for bytes at the port.  When bytes are detected, they are read.  

Did you ever find a solution?

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.

9 hours ago, ShaunR said:

Commented Out Diagrams?

No

Specifies whether LabVIEW returns dependencies that LabVIEW does not invoke, such as those in the Disable case of a Diagram Disable structure. Also, if you wire a constant to the selector terminal of a Case structure, LabVIEW considers dependencies in non-executing cases to be commented out and does not invoke them.

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

On 5/9/2016 at 10:59 AM, shoneill said:

Get VI Dependencies ignoring code inside a case with constant selector sounds like a bug to me.

I presume it works OK with inlined VIs?

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.

7 minutes ago, ShaunR said:

I create the file list similarly to you then I open each VI and check if it has dependencies (Get VI Dependencies Method Node). The VI opened and its dependencies are added to a [found] list. If a VI in the file list is already in the "found" list or in memory then it doesn't need to be opened and can be considered already processed (it has a parent that was previously opened). If a VI has no parent and has no dependencies then it is an orphan. It can also find VIs in conditional disables.

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:

1. 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).
2. 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.

39 minutes ago, austinman said:

jj321, My guess is that I am not the only person looking at your posting and wondering what will happen if I download and open/run your VI. If you are looking for a response it may be better to post a screen shot of your code and provide a little more background information.

If you are curious, here are why my alarm bells are ringing; you have never posted to the group before, the one liner description is scant on details, your user name makes me think you are hiding something, etc. In other words, your posting appears to have the potential to do my computer harm and will be treated as such by me. I suspect anyone else who is worried about downloading suspicious content will do the same. Based on the above I will be pressing the 'Report this Post' button.

If someone has downloaded the VI and sees no problems, please let us know.

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?

10 minutes ago, Michael Aivaliotis said:

One thing I like about the Q&A format is all the unanswered posts float to the top. It facilitates those wanting to help people.

Now that's a very good point. I didn't notice until now and I like it very much!

13 minutes ago, Michael Aivaliotis said:

I noticed many posts left unanswered. Why?

Because we missed said feature?