hooovahh

My job is to make sure my team works faster and more efficient, and also have more fun, I just need to add some high scores as well then we can have a competition :-)

Very neat.  How do you distribute the quick drop shortcuts to your team?  I've been using VIPM, I wasn't sure if there was anything else people use.

I heard an interesting idea at the CLA Summit, although I haven't tried it myself so I don't know how well it will work. Each time they launch the app they monitor change in windows memory usage from start to end and log it to a file. Then each time the application is opened, the memory usage is monitored and compared to this value from the previous time the application was run in order to calculate percentage loaded. I think this is what was done anyways, but I may be a bit off base. I supposed if you had some other process effecting your memory at the same time it could cause skewed results. But, it was an interesting concept nonetheless. 

I like the concept but in practice you may find it difficult to update the UI while the main.vi is being loaded.  I've noticed that when I do a Open VI Reference the UI is locked and doesn't update (something about thread swapping).  So I don't know how you would update a progress bar with the new memory loaded percentage.  The reason the the Sub-System loading works, is because there isn't one Open VI Reference call, there is one for each sub-system and then one for the main, and between each of these calls there is a time where the UI can be updated.  If you can get an example working using this memory usage method I would be very interested in how it works.

So, I've been bothered lately by bit.ly links. These are URLs to http://bit.ly/... that are ubiquitous across the web.

 

How many years have we preached to users, "Do NOT ever click on links that go to websites you do not trust? 

Oh live a little on the wild side once in a while.  Have you never visited a site with where the letter "s" is replaced with the letter "z" and you have more popups then Windows can handle.  When you've gone that far into the internet and survived without a virus, that is the day you have won.

I've noticed an up-tick in Arduino type questions on the NI forums. 

I have too, and I hope that means they will push for more refinement with the Arduino tool kit they made.  Possibly charge some small amount for it so it can get some more support and development.  I mean it works don't get me wrong, but I find minor bugs with it, and not officially supporting several Arduino boards.  It doesn't look like support has stopped (last revision was last August adding IR Transmit VIs) I would just expect more interest for low cost hardware when combined with rapid prototyping in LabVIEW.

It sounds like you're on the right track using virtual virgin machines to test your distributable. Quick question -- if you install the distributable on your dev machine, will it run without the three errors about missing dependencies? I'm guessing the answer is yes.

I recommend VMWare.  It's quick and easy to delete a disk image and paste a backup with just Windows installed.  The free version now allows making VMs even if it is called VMWare Player.

My apps are generally partitioned into sub-systems which are dynamically loaded so, apart from the UI, it just loads those then finally the UI (UI can be anywhere from 80% to 20% of the entire hierarchy....it doesn't really matter). All the "loading Plugin" is purely for me to see what I've missed or what has failed without waiting for everything. In the old days we used to just have a "VI Tree" which we would launch and the modern splash is just an extension of that. The only difference is that we can get the names and the number of those VIs and log them (if we want to).

Mine are too, I was just trying to make it more generic.  So that this loading splash screen with progress could be applied to applications where this dependency on sub-system architecture wasn't required.  I guess I'm satisfied with it as long as new applications also adhere to this design pattern.

Picture in SQL Server Tab which format is image bin,how to convert to picture format(BMP、JPGorPNG) and display in labview.

Some one have idea?

 

Thanks

I'm not familiar with the BIN file format for images.  It maybe a stream, which you can use with the Windows PictureBox.  If this is the case you can create a .NET Control in LabVIEW to open it.  If this isn't the case you may need to post an example BIN file so we can help understand what the file format is and how to view it.

I never looked into this too deeply, but it seems to me like the structure is simple enough - the top level in the EXE is the project (or maybe if there are other files in other folders it's not the top level) and everything else is relative to that exactly like it was in source. vi.lib and other such files are saved under a folder called 1abvi3w, if memory serves. All this should be easy enough to test manually by getting a reference to a few VIs inside the app and displaying or logging their path property (or you could just write a VI which will parse the entire hierarchy and go through the data manually).

 

For a more generic solution to your current method, what you can do is statically analyze the entire hierarchy (assuming you have a simple hierarchy with only a few top level VIs) and then list it in reverse and load all the VIs in the EXE in that order (i.e. from bottom to top). I think there was a thread last year which talked about this and maybe even had some examples (I have a vague recollection of Norm participating there, so you can go through his stuff).

Regarding 1abvi3w, I have seen this folder being generated temporarily when building an EXE, so I think this is probably correct and I can do some testing to see.  

I wasn't intending on loading all VIs one at a time then loading the top (from bottom to top) I thought that would be too time consuming.  Really I think what would work best is maybe to load the 20 largest VIs (by file size I guess) then load the main VI.  This way I don't have to load all 2000-5000 VIs, my goal would be to load just enough of them so that the progress bar can keep moving.  Maybe the 20 largest VIs will load 70% of the total VIs (because they would load dependencies) and then loading the Main would use the 70% already loaded, and just load the extra 30% it needs.  Just a thought I haven't fully tested any of this.

I haven't found another one yet unless someone would like to surprise me

This is all in the name of understanding right? I don't have it working but I wanted to share what I had to see if someone else could figure any more out.

So you can extract a newer LabVIEW EXE like Jim did and get the contents of it (I tested with 2011 EXE). However the contents may not be as useful as you'd like. There are alot of neat things like icon files, dialog information, version information etc. All of this isn't a big secret and can be viewed using Resource Hacker. You'll notice under the RCData there are a few sections and one of them should be much larger than the others. This the the main contents of your EXE and contains all the code needed to run (VIs, Controls, classes, and other files). In my two examples the large section was under "2" under the "RCDATA".

Looking at this 2 file I found a few block sections. Near the end there is the RSRC section and it mentions the "FLAG" block and "LVzp" block. The Flag block for me contained one byte that was 00 for the two EXEs I tested. LVzp contained the large majority of the "2" file and I believe this is the secret to the file's information. The LVzp block started with the same for the 2 EXEs I tested which is the following:

70 5A 6B D6 B4 55 AB 56 AD 5B

or in ASCII

pZkÖ´U«V

Now this is where I'm stuck. I'm guessing this pZk block is a compressed format of some kind but can't figure out what. Searching google for this header as a file returns nothing. I believe if we can decompress this we may have the file structure of the EXE listing out its contents.

I also did find some EXE_Miner on NI's site but it again only works with older versions of LabVIEW before this compression was done.

Nope Because I do it the same way

One page ago

 

The only real question is, how do you detect that the UI is initialised and ready to show since everything being loaded, doesn't necessarily mean the main FP can be shown (I use a queue or notifier for this, presumably you use an actress)?

DO'H.  Well it's been a while since I read this whole thread so I missed that.

Regarding how do I know my FP is ready to be shown?  Well my Main.VI isn't the main UI you see when you run, it goes like this.

Launcher

- Main VI

- - UI Actor

- - DAQ Actor

- - Logging Actor

- - Other Actors

My Launcher is as I described, a splash screen with a progress bar, cancel button, and opening actors one at a time then opening Main VI.  Main VI has some init stuff to do (read config files) then it calls all Actors to start.  Each Actor then has its own init operation (including UI Actor).  So my Main VI sits in a loop telling the UI Actor to Show Window.  It won't be able to do this until all init has been completed.  If Main VI doesn't hear the reply from the UI Actor:Show Window within a short timeout, it will wait then call the Show Window again.  When it finally does get the reply from the UI Actor, Main VI hides it self and UI Actor shows its self.

In this way my Launcher is a splash screen loading the VI hierarchy, and Main is a splash screen (without progress bar and cancel) that has the same front panel as Launcher.  This has a nice effect of a progress bar increasing then when it is full it disappears, and soon after the UI Actor is shown.  There are several flaws with this but after initial debug it works well.

My question back at you is how do you do you know where in the EXE your VIs are so you can open a reference to them in the Launcher?  Through trial and error I noticed that the path to the file within the EXE was the same as it was on disk from the project file to the Actor Core.  I wasn't sure if this was always true, and I wasn't sure where files that aren't relative to the project file are stored.  In source I have this structure.

C:ProjectsExample.lvproj

C:ProjectsActor 1Actor Core.vi

In the EXE it appears to be this

<dir>My Example Program.exe

<dir>My Example Program.exeActor 1Actor Core.vi

What about files not relative to the project like vi.lib files?  Where are they stored in the EXE and are they subject to change?

So I had an idea for a progress bar loading splash screen with a cancel option.  It's an idea that others have done before but I modified slightly.

There is a splash screen VI that is very small and then loads the main VI dynamically.  But how mine differs is I am able to have a progress bar loading each of the Actors, before loading the Main VI.  If you load the Main VI in the splash screen the UI will be locked until that Open Reference operation is complete because it needs to load the entire VI hierarchy.  So instead I will open a reference to each Actor Core, which is the majority of the VIs each actor will use.  During this a progress bar can be shown displaying which actor is being loaded and a cancel which would send a stop to the for loop loading each actor.  If cancel isn't pressed then after opening each actor, we then open the Main VI which takes much less time to load because each actor is already loaded.

This all works great but you may ask your self "How does the splash screen know what actors exist and need to be loaded without causing them to be loaded into memory already."  The only solution I came up with, is in my Build Specification I call a VI before making the EXE.  This VI will search my project for actor cores, and then write to the applications config INI file saying what the actor names are, and where in the EXE they can be found.  Then the loading splash screen reads this INI file and uses its information for the UI.

This all works and in practice loads quicker than just loading the Main VI dynamically, for some reason.  I tried making an example of what I described using the Actor Frame work but couldn't make it work due to my very VERY limited Actor Frame work experience.  I just used the term actor in this post so others would know what I was talking about.  But in general this could work for any producer consumer engine architecture that is broken up into sub components.  Heck this could work with anything with classes in it and just load each class before loading the Main.  Or even more generic what if we got a list of all VIs greater than a certain file size (say 50KB) then load each of them before loading the main.

Very cool indeed.  I wanted to make something, the best I could do is a face.

but now I would like to create something new. 

No need to make something new LabVIEW already has a peak detection.

<LabVIEW>vi.libmeasuremamon.llbWaveform Peak Detection for 1 Chan.vi

It's on the palette under Signal Processing >> Wfm Measure >> Waveform Monitoring

I think something like this could be in the idea exchange but would affect previously made VIs and their functionality enough that I don't think NI would implement it.  Right now if I have an error in the Variant to Data because of a type mismatch, the value I get out is the default value for the data type.  I think it should be the value wired into the Type terminal (similar to OpenG).

Secondly what your VI is doing is slightly different (correct me if I'm wrong).  It tries to match the data types based on the label name, not the data type it self.  At the moment the Variant to Data doesn't care about the labels at all.  I can have 2 clusters that have different labels, but the same data and the conversion will work properly.  If I had 2 labels swapped (change bool and num2) then the data won't be able to be set, and it won't be listed in the "Missing" array because it found matching labels.

Neat functionality but I don't have a use for it at the moment.

@rolfk

Regarding the LabVIEW stop / Car into wall situation.  I only use the LabVIEW stop in situations in development, when I know that all hardware and references I've opened, have been closed.  Similarly I am only talking about using kill as an option after all resources have been closed (File/DAQ/Queue/Events etc).

There is tons of details on how memory management works and I know very little.  I just don't know what kind of affect I will see (if any).  I've already released everything I care to release, and then tell Windows to remove the application from memory, terminating it and all of it's threads.  (I'm guessing it executes this Windows function)  What real issue could this cause?  Can anyone say doing this will cause an application to be corrupted?  Or for memory to not be released?

I'm not advocating this method, I just think it is a pretty simply way to make an application more Windows like (responsive close) and I have not seen any side effect yet.

A library *owns* a VI. A VI *is owned* by a library. The two have an indelible link. A VI may be owned by one and only one library.

 

A project merely uses a VI or library. The same VI or library may appear in many projects. A VI is only part of a project when the project is in memory. Any other time, there is no "owning" project.

I noticed today that there is a private method "Owning Project" and it works the way AQ mentioned where it would not work if the project owning it was not open.  As an experiment I added this VI to two projects and opened them at the same time.  The property worked as expected where the VI running in the context of one project would return a reference to that, and if it was running in the second projects context it would return that reference.  This property does differ slightly from the "Active Project" property which is a scripting method but not private.

NI does not support private methods and it's functionality may change unexpectedly so use with caution, or don't use it at all.

I have to ask... how did you do this?

Using a modified version of this.

That VI specifically flushes out the working set memory for the application running named "SeqEdit.exe", it can be changed to any application name.  Using this on any application will cause the working set memory to drop very low but as soon as you need memory again it climbs back up as expected.  Using this code I've never actually seen any problems get fixed, just prolong the inevitable.

Seemingly minor changes....can mean the difference between a working app and a quivering heap of unresponsive code.

 

Dave

I like this.  I'm going to steal this quote.

This is a prime example of digging around in LabVIEW and finding fool's gold instead of actual gold.

Dang, but my sincerest thank you for addressing this.

I don't think I have ever used 'Kill LabVIEW' in any executable the last 5 years. Why did you have to resort to it?

 

Ton

I don't have to resort to this I just don't know why it isn't immediate.  When I call quit I want the application out of memory within human noticeable speeds.  (say less than 500ms)

I can't say I use the quit/exit LabVIEW primitive anymore,

I'll add a case to my standard Quit if in RTE VI that has a kill as an option set to false by default.  If I see any issues this will be the first thing I change back.

Is this running on the same computer as the Development enivronment?

If this is true close LabVIEW entirely to ensure that it isn't holding the resource.  This isn't always necessary but if cleanup is not done properly this can be an issue.

What initially (because these are what have bit me) comes to mind is:

- Do you still have any code running at all that could take that long to terminate?

- How much memory are you using? How much of the memory is swapped out?

There is nothing running, after all code has stopped executing, and Actors have have performed their cleanup and then I call the Quit.  As for memory swapping out.  This is what can be used to show the biggest time in shut down.  If I force LabVIEW to release the working set of memory during normal execution, then Quit will take much longer to stop the EXE.  Now this is something I don't do regularly I just noticed it made it worst.  Even so why should this matter all my VIs are done running, when I say Quit why should it take a long time even if I did screwy things with memory.

I've run into this issue too (I don't have a fix for you).  I even take it a step further and close the front panel immediately, even without waiting for the loops to close.

That's fine and all but the EXE is still running.  I have the INI key of allowmultipleexecutions (it might be slightly different) set to FALSE, so if I exit (which just hides the UI) I can't restart the application until the last run is really done, which again may take a while.

Well. Ever since LV2010 I've noticed that even the IDE takes forever to shut down. I have assumed (rightly or wrongly) that it is something to do with making sure the run-time exits elegantly, so the implications of a task-kill may be subtle and/or horrendous in some unknown scenario (DAQ config?).

 

Suffice to say. NI have done something during the shut-down process that has increased the duration significantly. I would compare your software with one that has been compiled in 2009. I would expect it to exit far more promptly if it is down to the NI environment.

I also noticed longer shutdown time in newer versions.  But what could the run time engine be doing that is so important, where killing it would be bad if all the things I care about are closed out properly?  The problem with this question is no one but NI has a real answer, or could suggest why I shouldn't just kill it.

The most obvious (and most popular) answer is a state machine.  You can queue up your 25 operations and then do them one after another.  With a state machine you can have it update data, between states, or go to cleanup if something fails on step 15 or do what ever you want.  You aren't limited to performing the 25 states one after another until they are all complete.

I recommend a modified type of state machine called a Queued Message Handler (QMH).  Go to File >> New... and select the Queued Message Handler under VI >> From Template >> Frameworks >> Design Patterns.  This works in a similar way to a normal state machine but uses strings for the state names (not enums) and is more flexible, but also is more error prone (mis-spelled states for example).

So lets say I have a large application, lets pretend it is a 50MB EXE (it's not we are exaggerating).  I run this EXE and it runs for thousands of hours, then I close it.  When I close it all of the "Actors" run their own cleanup, and then the UI is hidden, then I call the Quit LabVIEW primitive.  If I look at the task manager the program still runs for some time after calling the Quit function but eventually leaves the task manager list.

I have seen in rare occasions (where I was messing with memory in ways I shouldn't) that caused the quit function to take up to a minute to actually exit.  What does this quit primitive do?  Why does quitting take longer than it should?  As a test I replaced the Quit LabVIEW, with a task kill operation on the EXE name.  Now when I hit the close button my application does the clean up on each Actor as it should, and then kills the program.  This operation now feels instant.

So is there something wrong with killing my program my way, after all logs have been closed, and hardware sessions closed?

EDIT: Okay so a search with Killing LabVIEW brought up this work around for killing an Actor based EXE.  So does this mean there is nothing wrong with killing other LabVIEW EXEs using this method?

I update type def'ed enums all the time.  I think almost all of the time I am adding new values to the end, not updating, or removing them, maybe this is safer since the constants already in my application aren't having their values changed.