Repeated Excel Headers

[try_guy90]

Hi all,

I have written a VI that takes data continuously and writes it to a queue. At a threshold cross trigger, it takes 1 additional second of data and then flushes the queue into an excel file. My problem is that when the data is exported, the headers I have programatically set for each column show up again every 100 or so data points in my output excel sheet. Can someone enlighten me as to why this is happenning? I have attached my VI and a sample data sheet output. 

Thanks,

Guy

[PalanivelThiruvenkadam · Accepted solution]

 I have used excel using activex control where we can use properties and methods to get our requirement done and i have nt used Report generation Tool kit with extensively.

so its Just a idea and from my past experience

Try to write empty values with Headers in the intialize state and the start to log the data without Feeding header

This may work good for you

[Bob_Schor]

You set Samples per Channel to 100.  In User State 1, you save these 100 samples to Excel, and specify the column headers.  So every time you save 100 samples, you tell Excel to write another set of column headers!

There's an easy fix.  Put the Column Header information in a Shift Register, set it in the Initialize State, and make it an empty array in User State 1, so it will only be defined for the first time you save 100 samples.

Bob Schor

[try_guy90]

Oops, sorry I didn't see your message until just now. I implemented the header write during the initialize state and it worked beautifully. Thank you! 

@Bob_Schor, that method sounds equally as good. Thank you for your input.

Guy

[James.M]

Bob is correct and that is the right way to do it. You are writing the headers every time you write data, which is every 100 samples.

Now, there are other issues with your code. I suggest you get rid of your Queue, because it isn't helping you at all. Instead, add your data to an array that you pass in a shift register like the rest of your info.

The way you have it now, you are actually losing all of your data except for the last queued element.

Right here, you're flushing your queue, then iterating through the queue elements, but then only using the last element. This may be fixed by setting the output terminal to Concatenating.

[try_guy90]

Thank you! I was wondering why my data was so small. I'm still working through a few bugs in my VI.

I am using a fixed size queue for the purpose of retaining only 2 seconds of data, however. I want the limit cross to trigger 1 more second of collection and then dump it all into the excel file. I will be collecting data at an extremely high rate at the time of the test, so I want most of it to be dumped as the VI runs. I am recording data surrounding an impact on a tank, which will be collected with accelerometers that give off a variable voltage reading (after going through a signal conditioner). How can I implement this without the queue, since you say it is not helping me at all?

Guy

[James.M]

A queue is helpful when you are communicating between loops for processing purposes. Here is what your queue is doing in a single loop:

1. Case 1: Enqueue data
2. Case 2: Enqueue data, Flush queue, convert elements of flushed queue to array of data, Write to file.

This can be simplified to:

1. Case 1: Build Array of data
2. Case 2: Build Array of data, Write to file, Write empty array to shift register

Just pass an array through each iteration via a shift register. 

On a side note, you may want to think about combining all of your shift registers in to one or two. Commonly, developers will have a single data cluster that they access within each case with Unbundle By Name. It simplifies your block diagram quite a bit.

[try_guy90]

I hear you on the communication between loops, but if I only want two seconds of data (one before and one after the trigger), how can I limit what it is that I save to the excel file? 

I was advised by crossrulz and Bob_Schor to use the lossy enqueue/circular buffer method here... I'm not sure how to do what I want in the way that you are advising me to.

Also, thank you for the heads-up on the shift registers. I will implement the change you reccommended. 

Guy

[James.M]

Ah! I didn't notice it was a lossy queue. Go ahead and keep using that, just fix that data loss thing I mentioned above with your For loop.

The way you would do this with an array would be to take an array subset at the end before writing to file. But the lossy queue works just fine as long as you don't intend to change your sample rate or sample size after you've started the program. By the way, you can move the Obtain Queue code to the Initialize state to clean all that up and not need to use local variables.