New user needs help

[tperovic]

Hello,

Using LabView for the very first time, I'm trying to create an application
that reads a single analog input from an OPC server, displays and logs the
data so that later it can be viewed and exported to Excel. I went through
the tutorials and examples. I found the Write Datalog File and the NI Demo
OPC Client examples. I managed to combine the two examples so that now I can
read, display and log an analog input. Now I'm stuck but I think I learned
enough to ask the right questions and to understand the answers.

Before the main While Loop I open the data log file (D:\Temp\Data.log) then,
inside the loop, I acquire and display the analog input and, depending on
the position of a toggle switch, I log the data.

Pressing the Stop button terminate
s the main loop. After the loop I close
the data log file and open the File Dialog and export the binary data log
file to the comma-delimited text file selected by the user.

Q: How do I read and display the data in the data log file? I found the Read
Datalog File example but it requires quite a bit of programming to implement
panning, scrolling and zooming.

Q: Should I be using a waveform chart or graph to display the data log file?

Q: I'd like to close, export and reopen the binary data log file inside the
main while loop when the user presses a Save button. Pressing the Save
button would open the File Dialog, get the name of the destination file and
export the data to it. Maybe the whole exporting to spreadsheet file thing
should be a separate application.

Q: LabView seems to have some built-in data logging capabilities. I played
with it briefly but couldn't get it to do anything. Should I persue this
avenue?

Q: LabView is constantly polling the values of various buttons and tex
t
boxes that seldom change inside while loop. This seems very non-event driven
or am I doing something wrong?

Any suggestions would be greatly appreciated.

Tony Perovic
Compumation, Inc.

[Aaron Marks]

A lot of your questions are going to depend on how you want your final applicaiton to behave, but I'll see if I can clarify a little.

1)Generally the point of using a log file is that you can read data sets in, one record at a time. LabVIEW knows the size of the record and can read the number of records you specify without you having to know the actual length in bytes of each record. LabVIEW also keeps its place in the open file so that you can go forward or back from where you left off. If you want to to do panning and scrolling in a graph, you might just read in all your data. This ofcourse should probably not be done if you will be dealing with very large files.

2)Generally, you use charts while aquiring data, and Graphs when reviewing data, thou
gh it is your own preference. Just remember that a graph will only show what was last wired to it, while a chart will maintain a history. Also, remember that cursors can only be used on graphs.

3)This is another case of preference. It should be a fairly simple matter to incorporate this, especially if you are using a state machine type architecture.

4.LabVIEW's built in front panel datalogging can be very useful if you want to save all the data on the front panel of a VI at a particular time. It certainly cuts down the amount of file I/O programming you need to do. But it also does what it does and is hard to customize if you want to do something unique. Not very difficult to use though.

5)LabVIEW is not really an event driven language (yet), though there are ways to make it behave as such. You can eliminate a great deal of the usless polling by using a well designed architecture.

Feel free to ask follow up questions if you want me to expand on something.

[tperovic]

I see, use a chart to display the data as it's being acquired and logged
then use a graph to scroll and pan and also to use cursors.

> 3)This is another case of preference. It should be a fairly simple
> matter to incorporate this, especially if you are using a state
> machine type architecture.


That's just it, it's not


> 4.LabVIEW's built in front panel datalogging can be very useful if you
> want to save all the data on the front panel of a VI at a particular
> time. It certainly cuts down the amount of file I/O programming you
> need to do. But it also does what it does and is hard to customize if
> you want to do something unique. Not very difficult to use though.

[tperovic]

Sorry, pulled the trigger too soon...

I see, use a chart to display the data as it's being acquired and logged
then use a graph to scroll and pan and also to use cursors.

> 3)This is another case of preference. It should be a fairly simple
> matter to incorporate this, especially if you are using a state
> machine type architecture.

That's just it, building a trivial example that does just one thing is easy.
Building a real application that acquires, logs, displays, scrolls, pans and
exports data is a lot harder. I've spent over a week on this and have very
little to show for it. I'm learning a lot but I can't help the feeling that
there's an easier way. After all, isn't acquiring, logging, displaying,
scrolling, panning and exporting data LabView's prim
ary function? I found
examples for each of these functions but putting them togather in one
application difficult! Should it be?

> 4.LabVIEW's built in front panel datalogging can be very useful if you
> want to save all the data on the front panel of a VI at a particular
> time. It certainly cuts down the amount of file I/O programming you
> need to do. But it also does what it does and is hard to customize if
> you want to do something unique. Not very difficult to use though.

Please elaborate on the built in datalogging. I'm acquiring data from an OPC
server and displaying the data in a chart. Now what? Can't find any examples
and the documentation is unclear.

Thanks

[Aaron Marks]

Here is a pretty good KB with example about front panel logging:

http://zone.ni.com/devzone/conceptd.nsf/webmain/8C4EECACF084F8E986256802007B9186?OpenDocument

In a nutshell, front panel logging saves all the data currently on the front panel as a record, the same way you would save a cluster in a LabVIEW datalog file using the File I/O VI's. To enable this, you first have tell the VI what file to log to.
Operate>>Data Logging>>Change log file binding
Once that is done, you can click the option to automatically save at completion of the VI:
Operate>>Log at completion
or save the front panel data at arbitrary times by going to:
Operate>>Data Logging>>Log..

Each time the VI logs data, it appends the data log file. There are two ways to retrieve this data.

1)Retreive it throught the VI's front panel: Go to
Operate>>Data Logging>>Retrieve
At the top of the VI front panel it will give you a new toolbar with a record selector, time stamp, etc. You can flip quickly between each of the records using the selector and it will display that set of Data on the front panel. You can also delete records from here.

2)Retrieve the data on the Diagram: Drop the VI you logged data with onto a diagram, right click on it and select "Enable Database Access". LabVIEW puts a "halo" around it with one input and three outputs. You input what record you want to read and the VI will return that dataset as a cluster. It also returns the corresponding timestamp, and an EOF boolean which tells you if you have requested a record number not in the file (ie. only 4 records and I request the 5th).

As for you problems constructing an application, there is no right way to do things. We can explain individual tasks, but it is the responsibility of the developer to create applications. Knowing how to design efficient applications is something that comes with time and experience as in any other programing environment. Design tequniques for larger applications is something that is covered fairly well in the LabVIEW basics 2 course offered by National Instruments. Unfortuantley, its not the sort of thing that can be easily taught through dev exchange. Best I can do is offer suggestions.

Last time I suggested a state machine architecture.

http://zone.ni.com/devzone/conceptd.nsf/webmain/8C4EECACF084F8E986256802007B9186?OpenDocument
This is one of the best ways to get the event driven architecture your looking for.

[Tony Perovic]

Thanks for taking the time to help a frustrated user. I'll try it.

"Aaron Marks" wrote in message
news:506500000005000000294B0000-1004225886000@exchange.ni.com...
> Here is a pretty good KB with example about front panel logging:
>
>
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/c61f1fd208
e8c3e2862565a30075580e?OpenDocument
>
> In a nutshell, front panel logging saves all the data currently on the
> front panel as a record, the same way you would save a cluster in a
> LabVIEW datalog file using the File I/O VI's. To enable this, you
> first have tell the VI what file to log to.
> Operate>>Data Logging>>Change log file binding
> Once that is done, you can click the option to automatically save at
> completion of the VI:
> Operate>>Log at completion
> or save the front panel data at arbitrary times by going to:
> Operate>>Data Logging>>Log..
>
> Each time the VI logs data, it appends the data log file. There are
> two ways to retrieve this data.
>
> 1)Retreive it throught the VI's front panel: Go to
> Operate>>Data Logging>>Retrieve
> At the top of the VI front panel it will give you a new toolbar with a
> record selector, time stamp, etc. You can flip quickly between each
> of the records using the selector and it will display that set of Data
> on the front panel. You can also delete records from here.
>
> 2)Retrieve the data on the Diagram: Drop the VI you logged data with
> onto a diagram, right click on it and select "Enable Database Access".
> LabVIEW puts a "halo" around it with one input and three outputs. You
> input what record you want to read and the VI will return that dataset
> as a cluster. It also returns the corresponding timestamp, and an EOF
> boolean which tells you if you have requested a record number not in
> the file (ie. only 4 records and I request the 5th).
>
> As for you problems constructing an application, there is no right way
> to do things. We can explain individual tasks, but it is the
> responsibility of the developer to create applications. Knowing how
> to design efficient applications is something that comes with time and
> experience as in any other programing environment. Design tequniques
> for larger applications is something that is covered fairly well in
> the LabVIEW basics 2 course offered by National Instruments.
> Unfortuantley, its not the sort of thing that can be easily taught
> through dev exchange. Best I can do is offer suggestions.
>
> Last time I suggested a state machine architecture.
>
>
http://zone.ni.com/devzone/conceptd.nsf/webmain/8C4EECACF084F8E986256802007B9186?OpenDocument
>
> This is one of the best ways to get the event driven architecture your
> looking for.