08-07-2009 10:24 AM
Dennis Knutson mentioned the Rube Goldberg post for my VI saving data to a text file. I saw his solution to my problem, and agreed.
Old
New
08-07-2009 10:36 AM
ctolson wrote:Dennis Knutson mentioned the Rube Goldberg post for my VI saving data to a text file. I saw his solution to my problem, and agreed.
It is still more than twice as complicated as needed. You have 4 trains of duplicate operations and, unless you are worried about muticore optimizations, you could use a FOR loop.
08-10-2009 09:00 AM
This may not be the place to continue correcting code but I really don't like the idea of using any type of wait function in a while loop to control when operations are done. I see this over and over but what happens if someone wants to kill the program right away but they are taking data every 10 seconds with the way this is coded? The user hits stop and has to potentially wait 10 seconds for the program to actually stop! Try using a case structure and possibly a countdown timer to your advantage to fix this. I'm sure there are many other ways also, if anyone else wants to suggest something.
08-10-2009 09:59 AM
for(imstuck) wrote:This may not be the place to continue correcting code but I really don't like the idea of using any type of wait function in a while loop to control when operations are done.
You might want to start a new discussion in the LabVIEW board, because it is a general concern.
Problems occur in poorly desinged code with deeply stacked while loops and excessive use of sequences, for example. A well designed state machine will never have such issues.
You are right, hard waits should typically not be used for anything longer than fractions of a second, and ther are plenty of alternatives (such as events with dynamic timeout recalculations (example) as discussed here). A program needs to be able to react to user input, including stop commands, at any time. If you get long stalls, you're definitely doing something wrong. I don't think there is any literature that suggest to use long waits.
08-10-2009 10:45 AM
I have since posted an updated VI using an event structure for timing instead of the wait until ms multiple. I used my original post here.
08-20-2009 03:32 PM - edited 08-20-2009 03:33 PM
If you ever have the need for a zero(DBL) diagram constant, the easy way would be do use 4 controls, 10 diagram constants (6 string, 3 DBL, 1I32) and some fancy cluster and array operations.
(Spotted here, but cleaned up a bit)
09-13-2009 06:54 PM - edited 09-13-2009 06:56 PM
There are many ways to get a column from a 2D array.
The hard way would be do:
[transpose array...array subset...to dynamic data...from dynamic data... insert into array...array subset.... (Top of image, spotted here. The actual code was actually somewhat simplified to show only the main point 🐵
... or we could just index array (bottom of image). 😄
same result!
09-14-2009 08:30 AM
09-14-2009 08:50 AM
Ray.R wrote:
Maybe he/she wanted to know what dynamic data did. 😉
Haha, I like how they convert to dynamic data, then immediately convert back to double.
I'm still trying to understand why they did that.
09-14-2009 11:00 AM
The conversion to dynamic data was done anyway for an xy graph and table using express VIs (see original VI). Still, this does not excuse to tap into the dynamic data to get the column for the 1D DBL array output connector.
I have no clue how the [insert into array...array subset] originated.... 😉