From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
BreakPoint
LabVIEW Minutiae (that may bite you someday)
@tst wrote:
@Jeff Bohrer wrote:
Yes, we all got schooled by the white power ranger's intelligent choice to read LabVIEW's help file. Here
You do realize it's not a power ranger, right?
In any case, he seems to be multiplying.
YES, kinda looks like one though.
When I learned to round numbers, I learned that if the value is exactly between two integers, you always round up. LabVIEW, however, implements the IEEE754 standard for its math operations, and the default for that is the method known as "Banker's rounding", which rounds the value to the nearest EVEN integer:
If you want to implement the round-up method, the code is fairly simple - just do Round to -INF (X+0.5). Note that this also rounds up for negative numbers, so -3.5 will be rounded to -3.
This piece of code checks whether the click was inside the green rectangle:
Looks nice and simple, doesn't it? If the click is between 20 and 100 X and 30 and 50 Y, you're inside the rectangle. Great.
The only problem is that it's wrong. Clicking under the rectangle returns T, even though we're not in the rectangle.
You see, the In Range & Coerce primitive is set to the Compare Aggregates mode, because I figured that just means that LabVIEW takes the results of all the comparisons in the clusters and ANDs them, providing a nice, clean way of easily comparing an entire array or cluster. Turns out I was wrong. That's not what Compare Aggregates does.
What it actually does is to compare the elements in order, similar to what happens in a dictionary or a phone book. When we do an equality comparison, this is actually the same as ANDing the results, but if we do a greater-than or other inequality comparisons, it isn't.
As an example, consider the following - in a phone book, is "Smith, John" greater than "Smith, Jane"?
The answer is determined by comparing characters until we find the first character which doesn't match. In this case that would be "a" and "o". Since "o" is greater, John is greater than Jane. If John was called Doe instead of Smith, he would not have been greater than Jane, because "D" is not greater than "S".
Looking at it like this, this piece of code is similar to asking whether BR is greater than AZ. Since B is greater than A, we don't even need to check the second letter. Likewise, in the example above, clicking below the rectangle returns T, because the value is between 20 and 100 X.
)
Newer LabVIEW version have a great feature: You can right-click on graphs and export to excel (or text, or clipboard) and excel will open with a nice spreadsheet containing all data nicely arranged in columns and labeled.
Here's is the thing that just bit me:
I recently "upgraded" a 12 year old little quick&dirty simulation program because somebody wanted to make some simulations for a presentation. There was no save feature for certain traces shown on the graph, just for the main trace. Of course I get a call in the middle of the night asking how to save the data shown in the other traces.
Me: just right-click the graph and export to excel. (after all, it is now in LV 2010!)
Him (after some wait): Hey, does not work, all the y columns are zero! 😮
Apparently, the numbers are formatted according the the formatting of the respective axis (?). The Y-axis in question was formatted with no decimal places (Who cares, since the axis is not shown anyway, and has "loose fit" disabled, right). The data was <1E-5 and thus truncated to zero during the export. Changing the display format for the hidden y-axis fixed the problem. 🙂
