BreakPoint
Rube Goldberg Code
To append four DBLs to a file, we apparently need to take each and format it as integer (lossy!) then take the first one, bult it into a 1D array of strings with one element, then use insert into array to append the other strings. I have the nagging feeling that this could be simplified. 😄
The lossy factor is a pickle, if you want the file to be readable...
Also, this file is very dangerous if you want any chance of using the application globally. Half the world uses "," as separator, the other ".". Better make sure what you store uses ".", and what's shown uses what the user prefers...
Search LabVIEW like a graph! Just the tip of the iceberg (that sank the Titanic!)
(seen here, but also posted here)
Basically, we have long sequences with interactive greedy loops in several frames, and even a frame where many terminal (controls and indicators) are wired to their own local variable. Must be a text programmer! 😄
@altenbach wrote:
We have an existing 2D array and need to initiaize an array with the same size, containing all zeroes.We can do it the hard way or the easy way.
Somebody just kudoed this old post here and it is probably important to mention that this method is only fully safe for integer arrays. For example if the input is DBL and contains NaN, they would remain NaN and could cause unexpected results downstream.
@altenbach wrote:Somebody just kudoed this old post here and it is probably important to mention that this method is only fully safe for integer arrays. For example if the input is DBL and contains NaN, they would remain NaN and could cause unexpected results downstream.
This returns 0 regardless the input or numeric type.
Not sure what it does to performance. *0 might be slower that initialize array too though. Who knows without testing...
You'll loose the ability to inline the VI, for undisclosed reasons (probably "no priority").
wiebe@CARYA wrote:Not sure what it does to performance. *0 might be slower that initialize array too though. Who knows without testing...
You'll loose the ability to inline the VI, for undisclosed reasons (probably "no priority").
Alternatively "Hardcore" way using ClearMem() if preferred:
@Andrey_Dmitriev wrote:
wiebe@CARYA wrote:Not sure what it does to performance. *0 might be slower that initialize array too though. Who knows without testing...
You'll loose the ability to inline the VI, for undisclosed reasons (probably "no priority").
Alternatively "Hardcore" way using ClearMem() if preferred:
Esp. surprising when used with clusters and "constant" set:
wiebe@CARYA wrote:Esp. surprising when used with clusters and "constant" set:
It would only be a little surprising if it would work. Although not really. When you configure a parameter as constant, LabVIEW trusts you that your CLN does NOT modify the data. And it MAY then use optimization to avoid copies. The emphasis is on MAY. Since it is in an Inplace structure, chances are high that LabVIEW aggressively will optimize since you promised it that the Call Library Function did not modify memory. Basically this means it CAN validly simply optimize the right side of the Inplace structure away., but there is no guarantee that it will do so.
Never ever configure a reference parameter as constant in a CLN if the function legitimately can make modifications to it. It will heavily influence the LabVIEW optimizer and since you told it: "Trust me this function won't change the memory!" it may first execute your Clear Mem, then your Sum operation. And it may completely avoid writing back the memory pointer since nothing changed anyways.
And if you change the CLN to be executed in multithreading it may even execute the Sum and the CLN in two different threads quasi parallel. With the Sum function seeing part of the array cleared and part not yet. If you do not tell LabVIEW that the array is const, it will almost surely first schedule the Sum and then the CLN to avoid having to create a copy of the array for the CLN to stomp on.
