10-28-2015 11:44 PM
Hi all,
I am trying to monitor some test rigs by analysing their audit files.
In this specific case, the rig is generating multiple 100 line files in a specific folder. The code below is finding the last file and extracts the content of the last line of the last file.
Unfortunatelly, when a error occurs, the main software is generating not only an entry, but an avalanche of lines [not a specific amount of them, depending of how many alarms were set] and I am for the moment out of ideas of how I could identify and output the content of the first line containing "Critical" or "E-Stop" from that avalanche [line avalanche started at 22.27].
As example, the program above is extracting the yellow line, while I need the informations from the blue line.
Any idea on how I can do this?
Cheers,
Solved! Go to Solution.
10-29-2015 01:21 AM - edited 10-29-2015 01:22 AM
I cannot give you right now a specific solution, but some ideas...
I guess the code which you show, is inside a while loop, and you iterate it with a fairly high speed in order to capture any new file / new line in current file changes?
Try to change it in a way, so the code is keeping an index (in a shift register for example) which is the number of lines in the actual file at the previous iteration of the while loop. If the number of lines is increased when you check again the file content, you just have to search for the word "critical" or "E-stop" from index+1 line. This should work in principle.
When I had to deal with such file/directory monitoring, I have really found useful the following community example:
https://decibel.ni.com/content/docs/DOC-41654
Using these Events you do not need to poll the folder/file content from a while loop. Cleaner approach I feel...
I would also ask whether you have any driver/access option to interface LabVIEW to this "test rig" directly and not via log files? Once I had to do this when we did not have any other option, so we had to also monitor files created by a spectrometer software (no drivers, no interfaces) in a PC...not a lucky situation...
10-29-2015 01:46 AM
Hi Blokk,
Thank you for the "Event Based File and Folder Watcher" tip.
Regarding the code above, it is a SubVI executing once per second. I cannot increase the frequency because the full program is already designed to monitor another 14 rigs and I do not want to stress the internal network too much (I have built a version that is using a TCP/IP protocol to get the right info from each test rig and is dramatically reducing the data flow through the network but is not yet very stable).
Regarding the driver/access option, there is none implemented. I am stuck with these files.
Have a great day,
10-29-2015 06:29 AM
Attach a sample file along with your current attempt to make it easier for us to help.
My first thought is to turn the text into an array and search the column for your terms.
10-29-2015 07:32 AM
Hi Jim,
As requested, I have attached the SubVi code and the some of the audit files.
Thank you
10-29-2015 09:30 AM
Your audit files have the extension .xls, which implies that they are in the Microsoft Excel (97) binary format. When I double-click them, I get an error message saying "These are not Excel Files". Closer inspection reveals that they are actually Tab-delimited files, the type of file that LabVIEW calls "Delimited Spreadsheet" (which, I would argue, is misleading, as most people equate "Spreadsheet" with "Excel").
You can/should read this file with "Read Delimited Spreadsheet" (note that this is the new Function name in LabVIEW 2015 -- earlier versions of LabVIEW I think called this "Read Spreadsheet File"). This will give you immediately a 2D array of strings (I chose to read as Strings). Now you can find the column you want by searching the first row looking for the name, go to the next column to get the values, and now search that Column to find the first Entry you need. You now have the Row that you want.
Bob Schor
P.S. -- if you are also writing the code to generate these data, I recommend writing a header row (Date, Time, Origin, Alarm Description, etc.) and starting with subsequent rows, just write the values. It will make your Log smaller, potentially easier to read/scan (half the number of columns), and will (probably) look "more professional".
10-29-2015 09:32 AM
If you do choose to redo the file generation code, do not give these files the .xls extension. If you call them .csv (Comma separated variables), you will be able to open them in Excel without error (as Excel "understands" this text format). This is also the "default extension" for LabVIEW's "Spreadsheet" file functions.
BS
10-29-2015 10:23 AM
10-29-2015 01:54 PM
You could add this snippet to the top of your existing code. I've changed the array indicator to a table so I could highlight the row.
10-30-2015 08:52 AM - edited 10-30-2015 09:03 AM
Thank you all very much for the effort invested helping me to fix this problem.
I have found, based on your indications, a way to extract the relevant data from the audit file generated by the rig.
I still have one chance out of 60 to get the wrong feedback but this is another issue that I will approach if the program will not pass the trials.
Below, you can find the solution and the .vi
Nota Bene: String to 1D array __ogtk.vi is part of the OpenG