BreakPoint

[altenbach]

Here is one involving X-Controls.

Xcontrols are a bit complicated to configure, so it might not be clear what it means if the "data changed?" boolean in the action cluster is set to true.

For example, there is an event case name "Data Change", and the programmer might think that "data changed?" needs to be set to TRUE in that event case. (After all, if you write to a terminal, the data changes in some way, right? ...wrong! )

Bad idea, but you might never notice a problem until you do some profiling:

If "data changed?" is set to TRUE in the "Data Change" event of an xcontrol, writing to a plain local variable of the xcontrol in the main program actually fires any "value changed" event associated with the xcontrol, same as if you would write to a value(sgnl) property. This can lead to unexpected behavior.

[JackDunaway]

Wow! I just learned one that threw me for a loop! I rarely use the Expression Node, so when I tried to generate a simple parabola out of instinct I tried "x^2 + 2*x". You can imagine I was shocked to see the following drunken graph:

Apparently, the '^' operator is the XOR operator, not "to the power of" like I expected. This was clearly evident for such a simple formula, but could be much more insidious in a complex formula.

See here for the original thread where I ended up using "x*x + 2*x" as the example.

[elset191]

---

JackDunaway wrote: 

Apparently, the '^' operator is the XOR operator, not "to the power of" like I expected. This was clearly evident for such a simple formula, but could be much more insidious in a complex formula.

See here for the original thread where I ended up using "x*x + 2*x" as the example.

---

Not sure if you discovered it in your research, but ** is "to the power of".  i.e.  "x**2 + 2*x"

[altenbach]

The few syntax differences (formula node vs. parser) are a bit of a weak point and can be confusing.

Here is a list of some differences.

excerpt from the help:

---

The parser in the Mathematics VIs supports all elements that Formula Nodes support with the following exceptions:

• Variables—Only a, a0, ..., a9, ... z, z0, ..., z9, are valid.
• Logical, conditional, inequality, equality—?:,, &&, !=, ==, <, >, <=, and >= are not valid.
• Functions—atan2, max, min, mod, pow, rem, and sizeOfDim are not valid. You can use these functions in a Formula Node or use their corresponding LabVIEW functions.

...

The following table lists cases where Formula Nodes and the parser in the Mathematics VIs use different syntax.

Element	Formula Node	Parser VI Routine
	pi	pi(1) =, pi(2) = 2, 2pi or 2(pi) return an error
Exponentiation	**	^

The precedence of operators is the same for the Mathematics VIs as in Formula Nodes. Refer to Formula Parsing VIs for more information about specific Formula Parsing VIs.

The parser in the Mathematics VIs uses the following syntax:

function (argument)

[JackDunaway]

Have you ever heard of "Coerce to Type"? You may not realize you need this function to squash bugs waiting to happen in data type conversions and typecasts.

[mitulatbati]

I try to configure a case structure in a way that one case matches all the input strings started with "CurrentMeasurement" (and others.)

This results TRUE, if the input = "CurrentMt" and also TRUE if input = "Currenteasurement". But FALSE for "CurrentMeasuremen"

So what is the rule? In the help I find only hints for string ranges, for example stringe begin with a and b should be "a..c"

Mitulatbati

[altenbach]

---

mitulatbati wrote:

I try to configure a case structure in a way that one case matches all the input strings started with "CurrentMeasurement" (and others.)

---

This looks like a normal question looking for help, so please post it as a new thread in the LabVIEW forum.

[SteveChandler]

---

mitulatbati wrote:

I try to configure a case structure in a way that one case matches all the input strings started with "CurrentMeasurement" (and others.)

---

You just gave me an idea for the idea exchange. What if the string could be a regular expression?

[SteveChandler]

If an event structure is registered for an event but does not have a case for that event then firing that event will still reset the timeout timer for the structure.

Some people consider it a bug and others consider it to be expected behavior.

There is an interesting debate on Lava about this.

Anyone know why creating a snippet converts a control reference into a control?

[tst]

---

SteveChandler wrote:

Anyone know why creating a snippet converts a control reference into a control?

---

Because NI wants to encourage people to use the Code Capture Tool which doesn't have this issue and can back-save your snippet as well?