Better Way to Parse Event Data

[mcduff]

Attached is part of VI that I am trying to use for debugging purposes. Basically, it uses the Event Inspector to log almost all of the Event Data to a debugging log; the log also contain commands from various JKI State machines running. A sample of the log is below

Time                     VI                           Command

2.647235                 Main.vi                      Panel Close? Main.vi
2.647235                 Main.vi                      User Event Macro: Exit
2.647235                 Main.vi                      User Event Macro: Exit
2.647235                 UILoop.vi                    User Event Macro: Exit
2.647639                 Main.vi                      Macro: Exit
2.647655                 Main.vi                      Message: Exit

I almost got the "Event Logger" portion working correctly, the only problem is the Event logger uses the millisecond timer whereas the other part of my debugger uses the high resolution seconds as a timer. (The millisecond timer does not have the resolution.)

Anyway the attached VI is my attempt to parse the Event data in a way I can use it. It seems & looks cumbersome, and may even make the Rube Goldberg thread. I was wondering whether anyone had any optimizations they can suggest. I did not use regex because I thought that was the worst performer.

Code snippet below, VI attached. Default values are included in the VI.

Thanks

mcduff

[BertMcMahan]

Are you seeing performance issues or are you just trying to clean things up a bit? If the latter, I'd suggest breaking it into a subVI (or two or three). It's much easier to debug that way.

You could clean up the wires some for sure, but if it works from an algorithmic standpoint, why change it? What are you trying to gain?

[mcduff]

I would like it to be faster and use less resources; faster with more resources won't cut it. This VI will be running in the background continuously while a program is running. This tool is basically used for development purposes, as a means to try and debug multiple loops running simultaneously in the program. With it, I can monitor when the user clicks something and then see what messages get sent to what loops and what commands in the loops get executed. I would like to keep it compact and fast for the rare cases I include it in an exe for testing by somebody else. This way I can try to recreate any errors they got. As of now I am happy with it, but if can be improved, why not?

mcduff

[BertMcMahan]

Ah, I see. In that case, I'd suggest taking a big ol' block of raw data and doing some benchmarking. Break your code into subVI's and try running each of them to see where your slowdown is. There are a few things that could likely be improved- for example, you're allocating memory for a new array each time you do your Spreadsheet String to Array, so you could potentially pre-create your array before entering the For loop and avoid allocating memory each loop.

I'm not sure that's causing you any trouble of course, as it's a tiny array and the compiler may take care of it for you. I'm just giving an example.

I'd bet once you get things broken down into multiple chunks you'll see really quick where your inefficiencies are and can focus there.

Another potential place to look is your second String to Array function. You only use that function part of the time, but you run it every time. Put that in a case structure instead of using Select, and it'll only run when it needs to instead of every time.

Once you get things broken down into subVI's you can try things like Scan from String or regex functions to see if any of them are faster.

[crossrulz]

Your parser does not match your example log data.  Based on your Index Array, it looks like there are 4 columns missing.  Do you have a more complete example?

As far as optimizations:

The first thing I would do is move your first Spreadsheet String To Array to be outside of the loop and have it form a 2D array.  You can then autoindex on the rows.

The next thing I would try is to get rid of is the second Spreadsheet String To Array by using a Match Pattern to search for the comma and take the "after substring".

[mcduff]

@crossrulz

Some background. (I initially should have explained my situation better)

LabVIEW has kept me employed, but it is only a fraction of my job. Most of the time I am doing other things. My background is chemistry without any real formal training in programming. Most of my LabVIEW work involves integrating a small amount of instrumentation for research and development, for example, laser control combined with DAQ equipment, motion control, etc.

My "go-to Project Template" is a collection of JKI State Machines that are linked via User Events as a messaging system. This template works well for the small programs I am asked to write. One problem I had was debugging my template, so I added my own debugger. Each State Machine that is running sends a time, VI name, and Command/State to a queue that records it in a log, like the one I posted earlier. It will also record any errors in the loop. Now I could see what loop processed what command at what time and debug any possible race conditions. Since the JKI State machine is event based, I also want the possibility of recording Events to my log. In order to record events, I need to use the API for the Event Inspector. Hooovahh and others have posted here and on lava on how to use the Event Inspector.

My problem now is how to parse the Event Data. That is the VI I posted earlier. You can open the Event Inspector Window to see how Event Data is recorded.

Why am I concerned about efficiency? We do a lot of field work where there is no "shore power" and we have to use our laptop with its internal battery, the less CPU cycles my program uses, the longer the battery can last.

Thanks for advice. I will have to play around with a 2D array idea, not sure how it would work at the moment. The default data I included is actual Event data. When there is a User Event I have an extra element in the data, when there is Front Panel Event like Panel Close? that element is not included.

I hope that makes sense.

Cheers,

mcduff

[mcduff]

This is slightly faster(~10-15%) than the previous iteration.

[Bob_Schor]

I notice you are parsing strings from the Event Inspector (which I haven't used).  Is it possible to output a "Cluster of Event Log Elements" instead of a "String of all the Elements"?  [I said "Cluster" instead of "Array", as an Event structure I created that I used to monitor some State Machines had a U32 for the Millisecond Clock, an Enum for the "Source of the Event", and a String for the Event, to accomodate numbers, strings, and Enums].  Might not be possible/practical, but thought I'd mention it ...

Bob Schor

[mcduff]

I am using the VI "EI Get Event Queue Data.vi" located in the ~\Program Files\National Instruments\LabVIEW 20XX\resource\dialog\Event Inspector folder. This VI returns the Event data in String Form, it is password protected, so I cannot change its output.

mcduff

[pauldavey]

You use a Select function to choose between 2 strings. You would get better performance if instead you use a case diagram since then it will only execute the required code (you choose the code instead of just choosing the string). There may be a little redundancy added (code duplication) but it should perform faster.