How to write a dual waveform to an Excel file without blank rows of cells

[Truckryder1]

Hi,

I am trying to write two waveforms into an Excel file, I am almost there, but the stumper is that after each row of data, a blank row appears in the XL file.

Probably something simple that I have overlooked, as I am pretty new at this.

Thanks in advance,

Joel

[RavensFan]

First, you do know that you are not actually creating Excel files, but just text files?  Even the filename that has the .xls extension is not an Excel file, and really shouldn't have that extension because it gets confused as an Excel file.  It should be .csv or .txt, or something else to distinguish it as a text file.

Which file path is giving you the extra blank row?  Or is it happening with both files?  What is your operating system?

Inside the Export Waveforms to Text file VI, the data string is being created with a carriage return/line feed as the end of row character.  The Write File function inside has the convert EOL set to True (default is normally False).  I wonder if it is doing an extra conversion in there and thus giving you an extra line feed or carriage return character.  Or perhaps however it is written in the file, Excel is creating an extra line during its import process.

You could try creating a copy of the subVI, give it a different name, and set the Convert EOL to False and see how that behaves.

[truckryder]

The one giving me trouble is the dual line display part.

The lower part of the block diagram works fine, writing each line one after the other, but the combined signals, seem to insert the return or EOL.

 (which is wierd as I am using the same sub VI to write to file)

I will go into it tomorrow when I am at that site, and try to find where that EOL is being inserted.

I have tried naming it as a csv, but that did not help.

I am using Windows 7.

Please share any other ideas that you might have on it.

Thanks for your help,

Joel

[RavensFan]

It may have something to do with the way the blue dynamic datatype wire is being converted.  As you can see, there is a coercion dot where the blue wire enters the subVI.  For the lower situation, you are using just a single waveform.

So at the top, instead of merging the two waveform wires (brown) into a blue datatype wire, just use Build Array and wire that into the Export Waveform subVI.

But looking closer into the subVI's.  I think there may be a bug.  (While I still wouldn't use the blue datatype wire, I don't think that is causing the problem here.)  You think you are using the same subVI, but actually it is a polymorphic subVI.  At the top, you are using the polymorphic instance that takes in a 1-D array of waveforms.  The lower subVI is the instance that takes a single waveform.

I'm not seeing an extra blank row.  But I am seeing an extra row that has some commas (the delimiter) in it with no associated data.

The 1-D instance of the subVI counts the number of waveforms in the waveform array.  It also tracks the the largest array among all the waveforms.  The problem is that once it gets the length of the largest array, it is doing a +1 to that thus making the 2-D string array larger than it should be.  (Look at the For Loop to the lower left of the subVI)  So it is creating an extra row with empty data, that once it gets converted to a spreadsheeet string, creates a row with delimiters but no data.

I'd appreciate it if someone from NI can look at this.  I believe it is a bug (this is looking at it in LV2011, but 2009 and 2010 also have this issue) and a CAR# should be issued.

[truckryder]

Do I need to contact NI on this, or will they pick it up from this blog.

Thanks again for your help,

Joel

[RavensFan]

They should pick it up from reading the forums.  I'd appreciate it if one of the other experts can look into this also and see if they agree with me.

NI should also look at the 2-D waveform version of this as well.  It as the same increment function in the same place.  However, in dealing with a 2-D array of waveforms (which I don't think has any logical real life value to ever need that version), you may need to have some sort of extra delimiter in there to distinguish the extra dimension of data.

If we don't here something from a blue bar NI employee in this thread in the next couple days, you may want to go ahead and call them.  Meanwhile, the fix for you would probably be to copy that subVI and name it something different, and eliminate that extra +1 increment function from the lower left.

[truckryder]

thanks I will try that and let you know how it works,

Joel

[RavensFan]

Good luck.

PS.  I mistyped and should have said "If we don't hear something from ..."

[truckryder]

No problem, I am used to reading emails that spell check has tossed up, and this fit right in.

😉

[Truckryder1]

Tried several ways to eliminate the EOL in the write to spreadsheed VI, none of them did the trick (or seemed to have any effect).

You are probably right about this being a bug.