Error in file export when order of elements in build array changes

[edu11]

Hi everyone,

A while ago I wrote a vi file which does the following:

At first it initializes a camera and chooses a region of interest (ROI). Data out of the ROI will be discarded.

Then it raster scans a motor stage in x and y direction, in bidirectional mode (meaning that x alternates between scanning from left to right and right to left as y is inreased).

For each point of the scan, the spectrum is collected, which is then integrated in lambda to give an idea of the total intensity.

Then the intensity is plotted, along with the spectrum at each point.

The final results are exported in a text file.

The problem:

If I flip the order of the wires in the "build array" before the file export, placing the Total Count (intensity) wire in place of the Spectrum wire, the file export fails. What I mean by "fails" is that the .txt file contains characters that look like chinese!

Why is that?

I attach my .vi as well as two screenshots which demostrate the problem.

[Hooovahh]

Such a little change, shouldn't have such a strange result.  I'd recommend using some debugging tools like highlight execution, probe, and breakpoint tools to see what the data is when it runs.

http://www.ni.com/gettingstarted/labviewbasics/debug.htm

[JÞB · Accepted solution]

---

@Hooovahh wrote:

Such a little change, shouldn't have such a strange result.  I'd recommend using some debugging tools like highlight execution, probe, and breakpoint tools to see what the data is when it runs.

http://www.ni.com/gettingstarted/labviewbasics/debug.htm

---

The Source is in 2011.  I can see a possibility and a potential work around for some things to try/

1. take the following steps

• Select each stacked sequence Right click and "Convert to Flat Sequence"
• Select each flat sequence and remove sequence

This might just fix it by itself you will want to turn on autogrow on surrounding structures

2. Lets look at the build array data

• For all wires that are sgl going to the build array insert a to dbl and an Allways copy

What I suspect LabVIEW is improperly reusing buffers for the sequence locals

[mikeporter]

Hey Jeff... The changes you recommend are all good (and necessary) but the thing I'm stuck on is that regardless of what happens to the floating point data, there's that built-in VI that changes it to string representations of the numbers. And as I understand it, that is where the problem is.

Mike...

PS: Coming to NI Week?

[edu11]

In the end it is not that important for me to find the solution, as the .txt file will then be processed by Matlab and I already found a way to plot everything I needed.

I will try some of these suggestions once I get some time on my hands.

Thanks to everyone who responded.

[JÞB]

---

@mikeporter wrote:

Hey Jeff... The changes you recommend are all good (and necessary) but the thing I'm stuck on is that regardless of what happens to the floating point data, there's that built-in VI that changes it to string representations of the numbers. And as I understand it, that is where the problem is.

Mike...

PS: Coming to NI Week?

---

Not this year

What scared me was the sgls on a SLs with no wire branch to force a data copy which, would force LabVIEW to preserve the sgls since the SL might need to be used again then, they get all mixed up building arrary out of mixed coerced sgls and dbls.  With the potential of a miss-reussed buffer (not uncommon in 2011) confusing the string operations in the write to spreadsheet.   The problem of course, must exist outside of write to spreadsheet file since it only exhibits with a build array element order change.  Or, we all are halucinating (Possible alternate theory)  

[edu11]

I am happy to report that the problem was resolved when I removed the stacked sequences, as instructed.

Thank you.

[JÞB]

Thanks for posting back with the results.  That's a nice tidbit of info to know about sequence locals (Not that I've used one in the last decade but I don't allways debug code that I wrote)