Conditional string building?

[SynergyMike]

I have a VI that checks several tests to determine which ones fail, and then builds a string to inform the user of the names of the failed tests. What I came up with seems kind of convoluted to me, and the code section does not work properly within the larger program where it is used, but it works fine on its own, so I suspect there is a dataflow timing issue.  Refer to the attached JPG. When used in the larger program, the first time the code executes, the resulting string is _always_ empty, but on the second run the correct text always shows up.  When run on its own, the correct text always shows up, even on the first run through.  I tried forcing the data flow in various ways by adding error clusters, but got nowhere with that.  Any suggestions?  Incidently, the numeric is produced by adding various combinations of 1, 2 and 4.

Regards,

Michael

[rex1030]

Explain more about your numeric

Message Edited by rex1030 on 06-23-2009 04:44 PM

[RavensFan]

Nothing jumps out at me.

Perhaps you can post the actual subVI and a sample of the larger program that demonstrates how you are using it with the subVI.

[RavensFan]

---

rex1030 wrote:
It looks like you are static casting the numeric into a boolean. This will mean that when the number is 1, it is true, else false. So unless the numerics you give it are 1 all the time then you will get a blank string.

---

No.  He is using number to boolean array.  So there will be an array of true's and false's based on the number.  That array will be autoindexed at the For loop.

[SynergyMike]

After spending a number of hours re-structuring my program so I wouldn't have to use the code I posted (I reasoned that I could use the routine that set the Numeric's value to build the string instead).  I then made a number of input and output routing changes based upon problems I had previously had with LabVIEW ignoring right side connector pane inputs (I assumed this might also apply to middle connections). 

When neither of those things helped, I spent several hours probing the program and finally found the real cause of my problem.

I had used several text indicators and local variables for same to access the value written to the indicators without enforcing any sort of dataflow between them.  I _assumed_ that since the locals were to the right of the indicator on the diagram that it would work, but this was not the case - apparently the locals were putting out blank values before the indicators were actually written to.  When I wired them directly, it worked just fine.

So.. now I have a different question - is there a good reference for LabVIEW's unwritten "rules"?  I have the LabVIEW Graphical Programming book and that covered some good topics, but I am hoping for something more comprehensive.

Regards,

Michael

[Dennis_Knutson]

There are actually a lot of 'written' rules. Open the on-line help and search for Style Guide.

[SynergyMike]

In my LabVIEW 7.1 installation, there is a PDF titled "LabVIEW Development Guidelines" that contains one chapter titled LabVIEW Style Guide, a mere 22 pages.  I was really looking for more detailed information than this.  On the two subjects I mentioned earlier, it has this to say:

"Avoid the use of local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data."

"LabVIEW uses a left-to-right layout so block diagrams need to follow this convention. While the positions of program elements do not determine execution order, avoid wiring from right to left. Only wires and structures determine execution order."

In the former case, the text does not explain what problems can arise from this.  Personally, I have found that judicious use of a _few_ locals can make a diagram much easier to read due to the un-crowding of connecting wires (and on diagrams that are more than one screen width, it helps keep the signals straight as well).

In the latter case, the text suggests that wiring input terminals to the right hand side of a connector pane should nonetheless work, even if the practice should be avoided.  As I have some functions with more than 5 inputs, I wired the extras to the right side and found those inputs were ignored.  When I used clusters to combine the inputs so I could keep them on the left, the code worked.  That's the sort of thing I mean by unwritten rules.

Regards,

Michael

[RavensFan]

The problem with using local variables is that it can lead to "race conditions"  (Search for that term to see numerous messages on the subject.)  It can disconnect the value stored in that control or indicator from normal data flow.  Suppose you read from a local variable and write to a local variable.  Can you guarantee whether the write operation or the read operation will occur first?  If you read from a variable before the data gets written to it, you could be reading old data.  If in the next iteration of the loop, the data happens to get written first, then the data written in the previous iteration would be lost never having been used anywhere.  As for extra copies of data generated by using the local variable, that may not matter for using simple scalar numbers.  But if you are using large arrays and datasets, the extra data copies could eat up your memory rather quickly.

Yes you can wire extra inputs to the right hand side of a connector panel.  And you can wire things from right to left.  But as a programmer looking at the code, you makes it harder to decipher what it going on.  If you try to limit wiring to left to right, then the act of reading the block diagram from left to right helps you figure out which way the data is flowing.

I wouldn't say any of these things are "unwritten rules."  They seem to be written.  And even if they are "rules" precisely, they are highly recommended "guidelines."

[GerdW]

Hi Michael,

"some functions with more than 5 inputs, I wired the extras to the right side and found those inputs were ignored"

I really like to see this! Show an example of this behaviour

[SynergyMike]

Like most programmers, I don't keep non-working versions of my code, and as this was several months ago, I no longer recall the details, and I would be wasting my time trying to prove a point if I spent time duplicating the code.  I do know that I wasn't hallucinating, however. 

But, to get back to the heart of the matter - let me ask my still unanswered question straight out:

Is there such a thing as a more than 22 page set of programming style guidelines for LabVIEW?

Regards,

Michael