From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-17-2009 11:03 PM
Hello LabVIEW gurus,
I have a project I am trying to get working that dissolves the distinction between data and VIs. It's called "LabLog" and the motto is: "the VI is the data". I am not a fan of any of the ways in which labview stores data. Log files are susceptible to corruption and are unreadable if the VI that created them changes its front panel. The other database methods are quite restrictive compared to the versatile ways in which you can simply store data on the front panel of a LabVIEW VI. The basic idea is that you can "log" the front panel by creating a copy of the VI (with the diagram removed) that stores the data as the default value). With LabVIEW 8.6, VIs are even more memory efficient. Plus, I have already made a "universal" viewer for looking at data. The method I am using works almost perfectly.
But here is my problem. The LabLog method only works when the user interface is "idle". I can drop the logger sub-VI in the diagram of any VI that I want to log, and it will create the LabLog VI once the program has finished executing. However, sometimes I want to log sub-VI panels that are running in a loop (for example). In that case, the logging will only record the last run (giving N identical copies if I run it N times). That is obviously not what I want.
Does anyone have a better suggestion of how to implement this idea (other than trying to convince me that I don't want what I do want)?
Any help is greatly appreciated!
Thanks,
Jeremy
02-17-2009 11:31 PM
I'm not sure what other database methods you are referring to that are, "...quite restrictive...". The fact of the matter is that a real database gives you the most flexible and secure mechanism for saving data. In addition, it does it in such a way that it is available across platforms and applications. Why do you think NI has an entire chapter in the Intermediate course now addressing databases. They recognize that databases are the preferred mechanism for storing data. This LabLog approach offers neither flexibility, security or accessibility. In addition, it guarantees that you as the LV developer will be saving the data, searching the data, maintaining the data, archiving the data, and reporting on the data. Plus, it is based on your ability to figure out how to work around features built into LV. Why go to all the trouble to recreate a wheel that is working just fine.
Mike...
PS: I know this isn't the kind of input you were looking for, but your basic concept is going to create massive headaches - which I don't think is what you want.
02-17-2009 11:48 PM
Mike,
I do appreciate the response, but what I am really looking for is a solution to my technical problem. As an experimental physicist, I am constantly creating new VIs to run my experiments. These experiments often have different data structures and I don't want to waste time trying to funnel my results into the more restrictive formats. I want to see, for example, 2D data plotted as intensity graphs in the format that I have created in my VI, using the same color tables, etc. It is restrictive to strip all of the formatting that is built-in to the LabVIEW front panel. And I don't want to spend a lot of time creating new data structures that can change from one hour to the next. The datalogging feature that is built-in to labview almost fulfills my needs, with the problems that I have already noted.
I realize that most people who use LabVIEW are trying to create nearly stand-alone packages for other users. In that case, it probably does make sense to go with standard databases. So I am not hoping that NI is gong to write this functionality that I desire for me and a handful of others. That is why I am trying to code it within the toolset that exists. And that is why I am enlisting the help of experts who may know how to solve my technical hurdles.
Jeremy
02-18-2009 04:14 PM
jeremy,
I do agree with Mike about storing data, but I do think I can give you a suggestion on your problem. You need to have your VI check to see if the file name already exists, if it does, it needs to create a new one. There is an example program on our community that has this functionality. Check out this VI and see if you can implement something like it in your code.