hooovahh

Here are my basic requirements:

1. It has to be web based. I move between different computers and I want to see the exact same thing on all of them, so not Outlook.
   
2. It has to be able to import my Reader subscriptions.
   
3. It has to allow the option of looking at each feed separately (If I understand correctly Outlook basically throws everything into your inbox and I don't want something like that).
   
4. I don't need something with a mobile app or anything like that. I usually only access these from PCs.
   

No recommendations but I did want to comment on number 3.  Outlook doesn't throw any RSS feeds into your inbox.  They have an RSS Feeds folder, then under that is a folder for each feed.  I also wasn't aware that Google Reader was going away.  I set it up a few years ago and used it off and on but I didn't like the way it did a few things so hardly used it.

Seems neat, so how is this different than a build array and index?

Your code makes me sad.  I've seen worst code before but your code should be cleaned up and documented before your project is complete.

First issue you will run into is the fact that your DAQ card is probably not a simultaneous sampling card.  So when you tell the card to read 1000 samples on two channels, it will read 1000 samples on one channel, then 1000 samples on the next channel.  So your samples will not be taken at the same time, and your phase will not be correct because by the time you are done taking 1000 samples on the first channel, the second waveform will have changed.  If you are taking measurements at the same time then this isn't an issue but many DAQ cards don't support this.

Have you tried graphing the two signals you read?  This may help in seeing why the phase calculation is not what you expect.

Attached is a VI that calculates the phase difference between two signals using the same technique you have and it gives the correct results even with noise.

Signal Phase.vi

I know the original issue has been solved but an alternative to polling for changes is using the System.IO.FileSystemWatcher class.

http://forums.ni.com/t5/LabVIEW/execute-vi-when-a-certain-file-is-in-a-certain-directory/m-p/397763?view=by_date_ascending#M198073

This VI can be modified to have file changes on a single file.

Assuming the accelerator exists, I usually simulate the Alt+? followed by the accelerator keypresses. 

Great suggestion.  Won't work in my case but thanks.  In my scenario (which I probably should have mentioned) I'm envisioning a time when a VI could be shown in a floating window, or in a subpanel.  When it is in a subpanel I would remove the menu bar (so it looks more like part of the main VI), and then have some other mechanism to run the menu bar from the main VI, possible through a right click menu.  When the menu bar isn't being seen (and in a subpanel) the Alt + F method (for file) doesn't work.  

I can of course catch the event of a separate right click menu and show the same options as a menu bar, I just thought if there is a way from the Main VI to call the menu item of the VI in a subpanel then no extra code would be required.

So in 2011 and 2012 with the super secret key turned on there is an "Invoke Built In Menu Item" for a VI.  It states very clearly "NOT IMPLEMENTED" so I assume don't use this your computer will explode.  

But this feature would be nice.  I was wondering if anyone had a method for invoking a menu item from a VI, and if anyone knew if/when this feature will be implemented?  I noticed there is a similar invoke method for an application, but this makes me think it won't work for a VI specific menu item.

So this is a bad example but I have a Help >> About Us menu item, how could I problematically call that as if the user pressed the menu item?  There are many, work arounds I just thought this would be one of the cleanest for my setup.

Are you seeing this when in a build EXE or just in source?  It took about 4 seconds in LabVIEW 2011 SP1 x86 within Windows 7 x64 to exit from source.  I have many OpenG packages installed.

Please post some of your code if possible.  Your claim is difficult to understand, unless there are other works at play.

Here's a post on Lava that mentions how to do it in Python (never tried it)

http://lavag.org/topic/15304-calculating-dynamic-formulas-with-boolean-operations/

Also it links to an NI site where another method can be used.

https://decibel.ni.com/content/docs/DOC-13186

I have topspeed database I inherited to work with and I have some files password protected. Is it any way to unlock those files.

 

Best Regards

Batimba

It is unclear if you are talking about the database being password protected or something else.  This is a LabVIEW forum and has little (if any) topspeed database experience.  If this is regarding LabVIEW please re-phrase the question so it is clear you are talking about LabVIEW.

I had a similar complaint (without knowing the platform issues) so I have made a small VI that is called "Is Path Valid and Exists?" which uses the two OpenG VIs "File Exists" and "Valid Path".  I never just use the "Valid Path" anymore.  You could do something similar where it needs to be "Valid Path", and Not "Empty String/Path"

If you have the "treat read-only VIs as locked". Otherwise, dirty dots can happen.

So if the file is read-only it can still be edited, (so a dirty dot) but you can't save it so any changes will not be kept, which in my mind is the real reason to set the file to read only.  Sure I could edit a VI that is read-only, keep it in memory and then the changes will be implemented, but as soon as I close LabVIEW (and changes are discarded) the VI will revert back to the original file.

 

Just out of curiousity... What's the use case for applying password protection on the VIs? I've never really thought about this before.

 

~Dan

Or to prevent accidental changes to VIs in the vi.lib.  Of course changing the file to be read-only maybe an easier alternative for this.

Well this is an interesting one.  I've seen this event before and I just never had a need for it so I never used it.  I assumed it worked the same way you wanted to use it.  I couldn't open your snippet (I believe Lava may have removed the meta data on upload) but I made a quick VI that was blank, and a new VI that opened its reference and tried to do what you did.  Sure enough I got the same error 1027.  

I tried tricking the method a few ways because I noticed if the VI was running I could register for the event but couldn't select any thing on the block diagram.  So I tried running the VI registering and then stopping it but that didn't work.  I also tried the "Fake Exec State" posted on Lava, and that didn't work either.

What was actually described there was a second EXE which functions as the splash screen. That second EXE saves what the RAM usage of the real EXE was after loading and then simply monitors RAM usage as the real EXE is loading and displays that as a percentage of the saved value. I'm assuming that should give a reasonably accurate answer, assuming a clean load of the app uses more-or-less the same amount of RAM (which may not actually be the case if you close the app and reopen, etc.).

Oh sorry I misunderstood.  In that case yes that would work decently well but probably not perfect.  Even so any of these suggestions are better then what we have now, when a Main.vi is the startup VI and takes upwards of 20 seconds before the user even sees anything indicating the program is running.

I found this way easier than vipm, to make sure all development system uses the right sets of VIs.

I suggest you try this, it's so easy, and has been working really good.

//Mike

I'm also going to side on Yair with the version issue.  At times I've had up to 9 versions of LabVIEW installed on my machine at once.  Unless you have a separate folder (or repository) for each version of LabVIEW there are going to be some issues for me using it.  And if you do have a separate location for each version then, when there is some bug fix I now need to fix it in each location.

Also I don't know how I feel about editing a users LabVIEW.ini.  On the one hand it should be no different then adding tools menu items, or quick drop functions, but for some reason I feel like the LabVIEW.ini is a place for a user to customize LabVIEW the way they prefer it.  What about the dreaded Auto Tool argument?  Am I to force all developers to not use Auto Tool (or force them to use it)?  Sure the majority of the settings we can all agree on (insert auto-feedback, terminals as icons, separate compiled code), I'm just thinking about the few that are user specific.

I also like the fact that I can take one VIPC file which can contain all internal and external reuse code, and settings, and take it to a computer that is offline.  There are many times where a PC will be in an environment where internet is not an option and bringing reuse tools and components (as well as SVN) are difficult.  Now I just grab one VIPC which is a snapshot of the reuse used on a project.  This is also great for configuration management because years down the road I can say exactly what VIs were used from the user.lib.  I guess SVN could do that too with revision tracking so that's not as big of a deal.

I'm glad it works for you but there are too many reasons for me to not use SVN for these types of changes. 

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.